  |
はてなキーワード: IPアドレスとは
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
https://anond.hatelabo.jp/20180415014902
FAKKUの利用を開始して3年が経過したので自分の知識をシェアしようと思う
・FAKKUとは
快楽天シリーズやBavel、X-EROS等の無修正版が読み放題
ただし日本からはアクセスできないようになっているためVPN必須
ちなみに海外に住んでいれば最新の快楽天も無修正で全部読めるよ
以下VPN使っても入れない、クレカ登録で弾かれる、ロリ系が読めないという人へ
・VPNについて
また最初はアクセスできたのに暫くして突然ブロックされることも
IPアドレスはニューヨークを選択しているがこれで今まで弾かれた経験無し
登録すればunlimitedの加入だけでなく無修正同人誌や単行本、エロゲの購入もできる
ホーム画面からsetting → account setting → Show Controversial Contentを『yes』に変更
以上
（FAKKU is temporarily down for maintenance.のページが表示される）
この場合はサーバーを切り替えや再接続でIPをコロコロ変えてるうちに繋がるようになります
面倒くさいですが……
アンチスレに突撃してる信者なんなのみたいな書き込みが理解できない
それをいうなら本スレに突撃してるアンチなんなのであってアンチスレは存在自体絶対悪みたいなもんなんだから突撃されたことに文句言ってること自体が相当盗人猛々しいというか。
そんでもって住み分けガーとかいって正当化図るとかどんだけ図々しいの。
言論の自由って何かに対して嫌いだと公言する自由も含まれてるの？それって最近規制対象になったヘイトスピーチと本質的にどう違うの？
文句言われたら謝るぐらいしおらしくアンチしてるならまだ理解できるけどなんでアンチに限って図々しいのかねえ。
どんなアンチスレも見つけ次第埋め立てでもなんでもして荒らされて潰されるべきだよ。
なんだだこのスレは…
https://medaka.5ch.net/test/read.cgi/doujin/1569465169/
本音がでたな。
まぁそういう馬鹿正直な増田のためにエスパーすると、規制されたって掲示板の管理人から直接じゃなくて使ってるプロバイダーから規制されたんだろ。
じゃないと増田の元に連絡が行く道理がない。まさか荒らしをやってる掲示板にメールアドレスを書き残してるわけもないし。
まず荒らしがあった掲示板の管理人はIPアドレスを調べて、どのプロバイダーのものか特定するんよ。
で、荒らしの書き込みログとサーバのアクセスログを突き合わせて証拠にしてプロバイダーに連絡する。
で、その連絡を受けたプロバイダーはその証拠ログと自分の手元に残ってるログを突き合わせて、嘘がないことを確認する。
それからプロバイダーがそのIPアドレスを使ってた人間、つまり増田に連絡して、荒らした掲示板はアク禁にするからって処分になるわけだ。
で、IPアドレスが一致するマンションはあるけど、そういうところはちゃんとプロバイダーが管理してて、住人の誰が荒らしたのかプロバイダーにもわからないなんてことはまずない。
この増田は はてな自体は自分のIDもIPアドレスも把握しているということを忘れているのではないか。この書き込みをはてなが歓迎するとでも思っているのか。
脅してるよーにも読めるから消したホーがいいぞ。
言ってることがよくわからん。企業の方針を推測するのがなんか問題あるの？
私はこの書き込みについて、自分のはてなIDがばれても全然困らないよ。なんだったら150ブクマ越えたらはてなIDを教えてもいいよ。
わたしはよくはてなブログに書く予定の内容の下書きとか事前反応調査に使ってるので
なくなるとやや不便だが
はてなブックマーク共々滅び去るべきサービスであるのは間違いない。
外部にも拡散される流れが強まるな。
すでにはてなでは死者をひとりだしておりその時点でははてなも被害者だったからあまり強く批判されなかったが
その後ほとんど何も対策してこなかったことが明らかにされるにしたがって上場企業としての存続にとってマイナスになる。
少なくともこんなサービスが残ったままだと
問題視されるようになるだろう
普通に考えればこんなサービス廃止すればいいだけだがメリットもあるため潰すには惜しいと運営が考えた場合に
→愉快犯のモチベーションを下げる。増田中心に話題が消費される現状を変える
・完全匿名ではなく、はてなIDとは別のはてな匿名独自のID表示をする
→今でもそうなのだがいざとなればすぐ正体が把握されるという現実を可視化する。おそらくだがやばい投稿をしているのはほとんど少数の同一人物だからだ
・言及された人による直接表現だけではなく、投稿のガイドラインを強めにする
→禁止ワードあるいは禁止表現に当たるものはアルゴリズムによる投稿制限を行うだけでなく取り消しを行う。その際に投稿者の画面からは規約違反で取り消されたことがわかるようにする
言い方はごちゃっとしてるが
「もう、運営はユーザーを完全には信用しないから完全なる自由にせず監視します」
という状態に持っていく
とか？
大型アップデートを控えた某ネトゲに関しての、愚痴と不満と未練です。消化不良な感情の行き処が無くて、書き遺す事にしました。
現在進行形でこのネトゲを楽しんでいて大好きだという人はなるべく読まないでください。
軽く自己紹介をすると自分は機械にもゲームにも疎いです。なので知識的な事は滅茶苦茶かと思います。
人気で有名なゲームシリーズのネトゲ版らしいですが過去作という同じタイトルのテレビゲームを一つも遊んだことがありません。
そんな自分が何故そのネトゲを始めたのかというと知人から「騙されたと思ってやってみてほしい」と言われてしまってついうっかりという理由です。
未練があるなら辞めなくてもよかったのでは？その通りですね、ストレスや苦痛が未練を上回ってしまいました。未練に関しては一番最後で言い訳していますのでそれだけ気になったなら最下部へどうぞ！
トップクラスの腕前を持つ人達と知り合えても完成されたコミュに所属している人達ばかりで、自分に入り込める余地がなかった。
自分がチームを立ち上げるために募集して頼み込み走り回りもしたけれど賛同を得られず、最終的に挑戦に必要な人数を集めることも出来なかった。
立ち上げメンバーの一人が自称未成年男性とのことでしたが途中でネトゲ内の女性にハマっておかしなことに。ネトゲあるある系の笑い話かもしれなくとも食らった側としてはキツい、気持ち悪い、そして迷惑だった。
「規約」という言葉がめちゃくちゃ。特に不満を感じた部分は「アカウント共有の禁止」についてと「外部ツールの使用禁止」について。
運営と同じ会社出身、過去シリーズ作品のスタッフで、そのネトゲ自体にもシナリオ提供という形で関わっているクリエイターが家族とのアカウント共有を宣言していたというものを見かけました。
それとは別に、暴言下ネタ辺りでGMに注意されている一般ユーザーのスクショをTwitterで見かけました。「うんことかちんちんとチャットで言ったのは自分ではなく弟です」と注意されているキャラが発言していた画像だと記憶しています。それに対するGMの返答が「家族であっても他人とのアカウント共有は規約違反なので今後弟さんに操作させないようお願いします」的なものだったと思う。
モニターの向こう側にいるのが誰なのか、運営側はゲームにアクセスているIPアドレスやマシンの事くらいしかわからないだろうし。例のクリエイターの「家族と共用」なんてIPアドレスもマシンも一緒だろうからGMが自宅に伺うくらいしないと共用かどうかの判別は無理ですよね。だから「アカウント共有の禁止」という規約に関しては、なんとなく掲げているだけにしか感じられない。
本来の「アカウント共有禁止」も代行(他プレイヤーにIDとパスワードを教えて代わりにログインとクリアを依頼する行為)の事を指すのであれば「常識的に考えて違反行為だ」とも理解できる。あんな例文(後述)を出す運営だし、アカウント共有の禁止についても「ご家族ご友人であっても」という一文を追加した方が良いのでは？そして違反者をきちんと罰してほしい。家庭内共有は前述の理由で正直無理だろうけど。
ふと思い出したけど、運営チーム所属のクリエイターが「(規約上プレイ可能年齢になっていない)子供にパッド渡したらキャラ動かしてた、かわいい～」的なのもあったような。
そして、例の「アカウント共有を公言したクリエイター」は生配信の際にデスクトップを映し、ACT(ダメージ計算などができるソフト)のアイコンががっつり写っていて炎上していたことも記憶に新しいですね。「今は運営会社や開発チームに所属していない外部のゲストクリエイター。彼は関係者じゃないだろうが」という意見もあったようですが、ゲーム会社のスタッフ事情に関して無知な自分から見ても、この「家族とアカウント共有宣言してデスクトップにACTアイコンを映したクリエイター」は運営側の人だと判断してしまいます。真剣にやったコンテンツの中心キャラの年齢を自分の判断で修正した的な事を言っていた覚えもあるし、これで運営側の人間じゃないというのは流石に無理かと。
クリエイターの細かい事情に無知な自分からしたら「このネトゲに関わっているスタッフが奥様にアカウント貸したりACT使ってるんだったらぶっちゃけもう公式はそれらを黙認してるっつう事じゃん」と、感じてしまいました。こいつが許されるなら一般人でも同じ行動が許されていいだろうよと。
引退した今だからこそ言えますが自分はACTを利用していました。利用しないと「遊べない」からです。正しくは「遊べない」ではなく「自分が理想とする遊び方が出来ない」に、訂正します。「なぜ自分自身の理想のプレイングにはACTが必要なのか？」ということも考えました。規約違反(のはず)だから、必要不要の問題じゃなくて使っちゃダメだ。とも思いつつ。
まず、ACTで計測をし出力されたゲームの結果をアップロードしてランキングを組成しているコミュニティサイトがあります。次に、海外のコミュニティには「そのサイトにアップロードしたデータの提出が可能な者に当コミュの大会への参加資格がある」というものがあります。そのコミュや大会に憧れを感じていて出場したかったんです。参加者は海外のプレイヤーばかりですが、自分が挑戦したいと思った大会で優勝したのは日本のチームでした。ACTがないと参加できない。導入が必須。規約違反にはなるけど導入しないと舞台に立てない！
実はACTというソフトには「5秒後にこういう攻撃が来る！ここが安全地帯だから移動して！」と教えてくれる機能を追加する事もできたそうで。これはネトゲ側で規約に明記されている「ゲームバランスを崩す機能を持つソフト」を使っているという扱いになりますよね。裏技。チート。ずる。そう呼ばれるものですよね。ちなみに機械音痴の自分には最後までそういった使い方の設定の方法がわかりませんでした。
特定のユーザーコミュニティへ参加するには「ACTで出力されたログ」が必須だったから導入せざるを得なくて使っていました。チームメイトの誰か1人だけがACTを導入してログを提出できる環境にあればいいので、自分自身がACTを導入する必要性がないと言われたらその通りです。が、チームの誰かは必ず導入しなくてはならない。なので結局その大会に参加しているチームの時点で規約違反もくそもあるかという感想です。ついでにACTが導入できるのはそのネトゲをパソコンで遊ぶプレイヤーだけなので「PS3(PS4)お断り事件」というものも過去にあったらしいと聞きました。くだらない。
ACTを利用せずにあのネトゲを遊び楽しんでいる人達も沢山いらっしゃるかと思います。前述したランキングサイトに巻き込まれるという形で載せられたりする事から、ACTやランキングサイトに悪い印象を抱いている人達もいるかと思います。「悪い印象」という言葉だけを取り上げるなら、読み上げツールと呼ばれるチート行為(「ここの安全地帯に移動してください」等と教えてくれる拡張機能)にいい印象はもちろんありません。自分が設定できないから僻んでいるんだねｗと言われたら何も言えませんが、ACT＝読み上げだと思っている人達も一定数いるようで。それを使っていなかった自分と読み上げ機能を使うユーザーを一緒にされることは不服ですが、どちらも同じACTユーザーです。ACTユーザーであるだけで「ツーラー」とも言われてしまいます。VCで有名なDiscordもツールですしDiscordユーザーもツーラーでは？と思いますね。ここにツッコミを入れようとすると限が無い。余談ですが「読み上げを使わないとギミック処理ができない馬鹿」がいると言われているようですが、自分は「設定すらできない馬鹿」の方でしたｗ
結局、ACTは刃物のように使う人次第で印象が変わるものだとゲーム＆機械音痴の自分は感じました。自分はただトップ層のプレイヤーになりたかったし、他部門で活躍するトッププレイヤーと交流してみたかった。だから必要だった。
まあもう、これ、運営が悪いじゃん。「ACTいらずのゲームシステムや設計や催し」を提供できていれば良かったわけで。運営から参加希望者に限定したランキングや大会を用意してくれていたら、トップを目指したいような人たちだけが参加するでしょうと。ACTは規約違反だから絶対に導入しないorプレステで遊んでるけどトップを目指せるなら参加してみたいという人達でもトッププレイヤーと認められるチャンスが得られる。しかも主催者が運営なら、公式に認められたトッププレイヤーになれるという事じゃないか。
冒頭で「自分は憧れの大会に出て実力を試したい、仲間になってください」とあちこちに頼み込んだりしていたと書きましたが、前向きに参加を検討してくれたフレンドに概要を伝える過程で「大会参加にはツール(＝ACT)必須なんですね。それらの使用は規約違反で利用者と関わりたくないから無理です」と断られた経験もありました。その後フレンドも切られ、通報もされただろうと当時は相当ビビりました。公式がツール不要のランキングを催してくれるのであれば、その人は一緒にトップを目指してくれていたかもしれないのに…と悔やんだ思い出が蘇りました。
ある意味トドメを刺してくれたのは例の例文発表でした。「大丈夫です、理解してます。ありがとうございます。」のあれですね。初めて読んだ時の感想は「うわ…」です。奥様とアカ共有＆デスクトップにACTのライターの件の時点で呆れてはいたのですが、あの例文公開で運営への不信感が限界突破しました。この通り、同じくらいのプレイヤースキルを持っていそうな「フリーの」仲間には恵まれず、自分は俗に言われる野良で遊んでばかりのプレイヤーでした。ご縁のあったトッププレイヤー達は所属や居場所があった。自分には無かったし作れなかったし入れてもらえなかった。野良参加が多い身としては、あの例文のケースを実際に目にしています。「慣れている人で周回しよう」という意図の募集に、メンバーを全滅させるミスを何度もする人。募集主はミスした人に「大丈夫ですか？」と尋ねてミスした人も「大丈夫です」とのことで「どんまい、気を取り直していこう！」からの、同じ人が同じ場所でミス。慣れている人で周回する募集なのに必ず間違えて全滅させ、時間ばかりが過ぎていく。これは迷惑行為ではないのでしょうか？30分あれば3周出来る面なので3周できるといいなーと参加したら、25分で1周も出来ず解散。毎回ミスをする人に対してですが時間返せよと感じました。「上手い人は下手な人に文句を言わない」「ゲームは時間に余裕がある人がやるべき」と言われたらその通りかもしれません。そして野良でしか遊べない人は固定を組む努力を怠っているからという言葉もあるみたいですが、自分だって一緒に上を目指してくれるメンバーを探し説得するという行動をしました。単純に自分とフレになってくれたトッププレイヤー達に遊びましょうと声を掛けてみたところで、断られる回数の方が多くそれにも疲れました。95％くらいが「〇〇時から固定だからごめんね」でした。「今日は疲れてるからやだよーｗやる気ないよーｗ」という断り方をしてくれる人の方が納得できたというか気持ちは良かったです。そのタイプの人は後日改めて声を掛けてくれることも多かったです。
しかし運営が一度示してしまったこの方針(「理解しています、大丈夫です」のミスる人に「理解していませんよね？」と何度も言ってはいけない)が続くようであれば「不慣れな人たちがあわよくばの気持ちで進行度や腕前をごまかし募集に入ること」が増えてしまうだろうし「面の皮が厚い奴ほど得を出来るゲームシステム」という事がさらに加速しただろうなと。やってらんね、となったわけです。
過去にUOやRO等を遊びネトゲ経験値の多い叔父が親戚にいます。もちろんこのネトゲも遊んでいた時期があり、魅力的なNPCやそのNPC達とダンジョン探索ができること等を評価していたけれど運営やシステムに愛想を尽かし辞めたそうです。ついでに「例の文についてどう思いますか？」と振ったらただ一言「民度やば」と。運営はなぜあの例文を公開したんでしょうか。謎です。
少しずつ蓄積していった不満もあります。この機会なので吐き出しておきます。確かにクリエイターという存在はこのネトゲにとっては創造主・神様かもしれない。けれどこのネトゲ内で数多く存在している「開発スタッフを崇拝する独特の空気」も最後まで理解することができなかった。ACTとも無縁だった一年くらい前の話。宝探しでハズレが出たときにスタッフの名前をチャットで叫ぶ行為が多発し、由来を調べた結果、率直に気持ち悪いと感じました。「(クリエイター崇拝を)気持ち悪いと思うならこのゲームは合わない。やめたら？このゲーム。」という風潮まであるらしく。そして、アップデート予定等をユーザーに伝える公式生放送でスタッフが着ていた私服が話題になり同じ品を特定し購入したユーザー達でとても盛り上がっていた…という出来事にも気持ち悪さを感じました。これは個人の意見です。
クリエイター崇拝といえば、冒頭から何度も書いている「奥様とアカ共有＆デスクトップにACTのライター」は人として大嫌いです。悪い人という印象しかありません。その人の役職が何なのかすら実はよく理解していないのですが、大嫌いになりました。作家の人間性で作品や登場人物の善し悪しを決めたくはないけど、ファンを通り越した信者が「オキニのA君がカッコイイのは〇〇様が産み出してくれたからです！ありがたや～」とキャラ以上にクリエイター本人を持ち上げている内容が目に入ってしまって、そのキャラへの印象も残念ですが下がってしまいました。具体的ですが道を開けい！のお殿様はキャラとして結構好きだった。はず、だけど、気付けば苦手になっていました。お殿様に罪はないのに…
こうして今残っているユーザー層や運営の方針に愛想を尽かし、自分の分身でもあったキャラを消し、そのネトゲ世界から遠ざかるという決断をしました。
仕事で必要になった旧ノーパソのブラウザにランキングサイトが開きっぱなしで残ってたり、バージョンアップが控えているのもあって嫌でも情報が目に入ってきてしまった。道路ど真ん中のうんち踏んだ。
そしてよ。参加する事にずっと憧れていた海外コミュの大会がよ、発表されてよ？未練ダラダラだなおいって言われたらそこまでだ、その大会の種目内容じゃあ未練デロデロにもなるわクソが！
突如開催が発表されたその大会のエントリー締切日は今日なので、この遺言を見た実力者は自分の代わりに参加してきてください。よろしくお願いいたします。
もう自分のパソコンには、そのネトゲ本体もACTもランキングサイト専用のアップローダーも無い。
成仏しなきゃ。
以前、某Webサイト制作大手で仕事していた際、大量の犯行予告に対応した機会があるので書いておく。
連中も一枚岩ではなく、模倣犯も多分にいるため一概には言えないが、メッセージの傾向からしなんJではなく、唐澤弁護士をおもちゃにして遊んでいる連中が主犯。
真面目に犯行予告しているものは皆無で、爆弾を114514個仕掛けた、など一見していたずらと分かるような書き方になっている傾向が強い。
犯行予告で報道されているものは氷山の一角で、予告が来ても単に無視されることがほとんど。
ひどいときは、GW中に爆破予告されたが担当が休みだったため確認したのがGW明けで、確認した時には予告日を既に過ぎていたとかいうこともあった。
報道された犯行予告のうち、実際に逮捕まで行くのは更に少ない。予告が通報されると警察からWebサーバのアクセスログの提出を求められるが
犯行予告のノウハウが共有されているのか、IPアドレスが匿名化されていることが多く、そうなると迷宮入りになる。
生IPで予告していた奴は1件だけ見たことあるが、そいつはめでたく捕まっていた。
日本で予告通りに爆破があった事件は、三菱重工爆破事件依頼発生していないし、
だから真面目に取り合う必要はない、という考え方はごもっともである。事件化した方が予告者は面白がるのも間違いない。
ただ、殺害予告に対して脅威を感じて被害届を出した者に対して、これをいうのは正気ではない。
脅迫が実際に行われないのだから通報は無意味だ、というのは、脅迫自体が与える心理的影響を完全に無視している。
なんJやらに入り浸っていれば内輪の冗談の範疇かもしれないが、それを知らない者にとっては十分にリアルな殺害予告だ。
そもそも狂人の真似をしたアホと本物の狂人を見分けるのは本人以外には不可能である以上、リアルな殺害予告として扱うほかない。
北守もそれをわかっていないわけではなく、しかし党派性がゆえに腐してやりたかったためのいっちょかみが燃えてしまった、というのが本当のところだろう。
