背景
こちら1を受講したところ責任共有モデルなどのAWSがクラウド活用意義を説いている思想を網羅できていないと感じたため整理する。
※”思想系”は勝手に呼称しました。
責任共有モデル2
コース1では以下の図を暗記しましょうと言っていた。EC2などのIaaSのサービスを考えれば当然なことを言っているような気もする。
-
AWS利用者（我々AWSユーザーが以下について責任を持たなければいけない）
- データ
- 当然S3やDBに入れるデータはAWSが感知するわけもないのでこちらで責任を持つ
- プラットフォーム、アプリケーション、IDとアクセス管理
- プラットフォーム:
- アプリケーション: こちらで作るものなのだから、バグがあればこちらの責任。
- IDとアクセス管理: SystemManagerなどで管理する方法は与えられているので、こちらで対応する。アクセス管理はIAMの権限で対応可能。
- オペレーティングシステム ネットワーク、ファイアウォール構成
- オペレーティングシステムはEC2などでは様々なOSが選択できるようになっているが、セキュリティパッチなどを適宜実施するのは利用者側ということ。
- ネットワーク：システムのマルチAZ構成などの冗長性を指す？
- ファイアウォール構成：セキュリティグループやNetworkACLで管理できる。
- クライアント側のデータ暗号化とデータ整合性認証
- Cognitoなどを用いるか用いないかは利用者の判断にゆだねるということ。
- サーバー側の暗号化（ファイルシステムやデータ）
- SSE-KMSなどの機能が提供されているように、必要に応じてユーザが自身で適用する必要がある。
- ネットワークトラフィック保護（暗号化、整合性、アイデンティティ）
- VPCFlowでVPC内のトラフィックを確認する手段や、
- データ
-
AWS (利用者は以下を意識する必要はない)
- ソフトウェア
- コンピュート
- ストレージ
- ハードウェアと同様
- データベース
- 復旧時のデータのバックアップ処理などはAWS側が機能として提供している。
- ネットワーキング
- L2スイッチ云々のことを意識しなくてよい。
- ハードウェア
- メモリが故障責任などはAWS側。
- Region
- AZ
- エッジロケーション
- データセンタの内部の話やらそれらが地理的どう配置されているか、物理的なセキュリティ体制などはAWSしか知りえないので当然AWS側の責任。
Ref サービスの分類
- Iaas (Infrastructure as a Service)
- EC2などに代表されるハードウェアのみを担保するのでそれ以上のOSやミドルウェア、アプリは利用者側で責任を持つ形態
- Ex. EC2 etc.
- PaaS (Platform as a Service)
- 利用者はアプリ開発に集中できる。osやミドルウェアを意識しなくてもよい。
- Ex. Lambda, RDS etc.
- SaaS (Software as a Service)
- Serviceレベルで提供している
- Ex. AWSのマネージドサービスがこれにあたる。S3, DynamoDB, SQS, Lex, etc.
AWS Well-Architected3
- 6つの柱
-
オペレーショナルエクセレンスの柱
- Cloud Watch EventやEvent BridgeなどによるEvent Drivenなシステム
- CloudFormationによるリソースの自動作成
- CodeDeploy、CodeBuild、CodePipeline、CodeRunによるCI/CDの構築
- SNSでの自動通知
- Cloud WatchやVPC Flowlogs, Cloud Trail, などによるログ収集・管理
-
セキュリティの柱
- IAMによる最小権限の付与
- KMSによる暗号化・鍵管理
- 各リソースのPolicyによる権限付与
- ACLやセキュリティグループなどによるアクセス制御
-
信頼性の柱
- AutoScaleなどの可用性
- DynamoDBなんかのPoint In Time RecoveryやBackupなど
-
パフォーマンス効率の柱
- ビジネスニーズに応じたコンピューティングリソースを扱えること。
- エッジロケーションの仕組みを利用した応答速度の向上などもここか。
-
コスト最適化の柱
- スケールアップ/ダウン・アウト/インによるコスト最適化。
- LambdaやDynamoDBなどのオンデマンド課金（またはプロビジョンド）を選択できること。
- EC2のリザーブド・スポットインスタンスなどが該当
-
持続可能性の柱
- スケールアップ/ダウン・アウト/インによるリソース使用率の最適化
-
オペレーショナルエクセレンスの柱
AWS アーキテクチャセンター4
- 思想ではないが、Well-architectedを調べていくうちにたどり着いたのでここで。
- アーキテクチャのベストプラクティス・参考情報が手に入る。
AWS Cloud Economics5
4 つの主要な価値に対する進捗状況を測定および追跡することで、組織がクラウドの包括的なビジネスケースを構築できるようにする Cloud Value Framework
これ6 の P.4-5 によると以下4つの柱とその持続可能性を指す。
- コスト削減 (Cost Savings)
- オンプレの高い固定費から脱却することでTCOを削減できる。
- スタッフの生産性 (Staff Productivity)
- Tactic Work(意思決定に必要な情報の収集などの戦術としての具体的な仕事)、ログの監視やスケールアップダウンなどのためのリソース使用率などを自動監視できるようになるため、これまで人間が介在し行っていた業務をやる必要がなくなることで、エンジニアが生産的業務に集中できるようになる。
- 運用上の回復力 (Operational Resilience)
- EC2などはデフォルトで自動復旧される。7
- ALBなどはHealthCheckが失敗すると自動復旧を試みる。
- CloudWatchはメトリクスの管理を常時実行可能
- ビジネスの敏捷性 (Business Agility)
- ManagedServiceはいくつも存在するので、その利用だけでも0から作るよりもはるかにビジネスを実現することは可能。LexやComprehend,Textractなどの機械学習系はわかりやすい例。
- スタッフの生産性の向上で上げたこともここにつながる。
- Sustainability
- 事業継続性ではなく、環境に対するインパクトのことを指している。
- 要するにリソースの無駄をなくすことは省電力化につながりエコだよねってこと。
AWS クラウド導入フレームワーク (AWS CAF)8
- クラウドトランスフォーメーションとビジネスを評価し、加速させるためのガイドライン。
- 6つのパースペクティブ
-
ビジネス
- ステークホルダー: CEO, CFO, COO, CIO, CTO etc.
- クラウド投資を支援する。
-
人材
- ステークホルダー: COO, CIO, CTO, ディレクター, リーダー etc.
- 組織・リーダーシップ・変化が当たり前になるような文化への進化を支援
-
ガバナンス
- ステークホルダー: CIO, CTO, CFO, 最高データ責任者, 最高リスク責任者 etc.
- リスクを最小限に抑え、組織の利益を最大化すること
-
プラットフォーム
- ステークホルダー: CTO, テクノロジーリーダー, アーキテクト, エンジニア etc.
- スケーラブルなハイブリッドクラウドプラットフォームの構築、ワークロードの近代化, クラウドソリューションの導入を支援
-
セキュリティ
- ステークホルダー: CISO(最高情報セキュリティ責任者), COO, 内部監査のリーダー, セキュリティアーキテクト, エンジニア etc.
- データ、クラウドワークロードの気密性、完全性、可溶性の実現を支援
-
オペレーション
- ステークホルダー: インフラリーダー、サイト信頼性エンジニア、情報技術サービスマネージャー etc.
- ビジネスニーズを満たすレベルでクラウドサービスが提供できるように支援
-
ビジネス
一般的な設計原則9
- 必要なキャパシティを推測しない
- スケールアップ/ダウンを適用する
- 本番規模でシステムをテストする
- 本番デプロイ時との差異を最小化することでリスク低減する
- テスト完了後すぐ削除する
- アーキテクチャの実験を自動化する
- 反復可能な環境を作成することでコスト削減する
- 発展的なアーキテクチャを受け入れる
- 変化するビジネス要件に対応できるようにクラウドでオンデマンドにサービスを構築しよう
- データを使用してアーキテクチャを決定する
- 経験や勘ではなくデータでかんがえる
- ゲームデーを通して向上を図る
- ゲームデー；障害などをシミュレーションする日 を取り決める。