この記事に書かれていること
Well-Architected Framework の一般的な設計原則と６つのフレームワークの柱の設計原則を簡単にまとめたものです。
Well-Architected Framework に書かれている内容が大体わかる程度の記事なのでご了承ください。
詳細はAWSドキュメントをご覧ください。（https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/welcome.html）
Well-Architected Frameworkとは
AWSの過去の経験に基づいた設計原則、アーキテクチャのベストプラクティス集
一般的な設計の原則
- キャパシティニーズの推測が不要
- 自動的にスケールアップ/スケールダウンを行う。
- 本稼働スケールでシステムをテスト
- 実行時のみ費用が発生するのでテスト環境を本番環境と同じスケールで用意できる。
- 発展するアーキテクチャが可能に
- オンプレと比較して設計変更がしやすいので、継続的にアーキテクチャを変更できる。
- データに基づいてアーキテクチャを駆動
- メトリクスを収集して適切なアーキテクチャを選択する。
- ゲームデーを利用して改善する
- 障害などをシミュレートしてアーキテクチャとプロセスのパフォーマンスをテストして、改善する。
- ゲームデー：障害対応のシミュレーション。
フレームワークの柱
設計の際に考慮すべき６つの柱
- 運用上の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- サステナビリティ
６つの柱のそれぞれの設計原則を以下に記載しています。
運用上の優秀性
- 運用をコードとして実行する
- アプリだけではなくインフラもコードで定義する。運用手順をコードで実装し、自動化することで人為的なミスを抑制する。
- 小規模かつ可逆的な変更を頻繁に行う
- コンポーネントを定期的に更新できるようにワークロードを設計する。変更は失敗した場合に戻せるように小規模に行う。
- 運用手順を頻繁に改善する
- 定期的に運用が効果的であるかを検証し、改善する。
- 障害を予想する
- まだ発生していない潜在的な障害の原因を明らかにして排除または軽減する。
- 運用上の障害すべてから学ぶ
- これまでに発生した障害から得られた教訓を基に改善する。教訓はチーム間と組織全体で共有する。
セキュリティ
- 強力なアイデンティティ基盤を実装する
- 最小特権の原則で適切な権限を付与して役割を分担する。ID管理を一元化し、長期間にわたって一つの認証情報を使用し続けないようにする。
- トレーサビリティの実現
- リアルタイムかつ自動でモニタリング、アラート、監査のアクションと変更を行う。
- 全レイヤーでセキュリティを適用する
- ネットワークのエッジ、VPC、ロードバランシング、すべてのインスタンスとコンピューティングサービス、オペレーティングシステム、アプリケーション、コードなど、全レイヤーにセキュリティを適用する。
- セキュリティのベストプラクティスを自動化する
- バージョン管理したコードでセキュアなアーキテクチャを作成する。
- 伝送中及び保管中のデータを保護する
- データを機密性レベルに分類して、暗号化、トークン分割、アクセスコントロールなどを適用する。
- データに人の手を入れない
- ツールを利用し、データへの直接アクセスなどの手作業を低減または排除して、機密性の高いデータを扱う際の誤処理、改変、ヒューマンエラーのリスクを軽減する。
- セキュリティイベントに備える
- インシデント対応シミュレーションを実行して、ツールとオートメーションで検出、調査、復旧のスピードを上げる。
信頼性
- 障害から自動的に復旧する
- ビジネス価値に関するKPIをモニタリングして、閾値を超えた場合に自動で復旧プロセスを実行する。
- 復旧手順をテストする
- 自動化により様々な障害や過去の障害シナリオの再現を行い、復旧手順を検証する。
- 水平方向にスケールしてワークロード全体の可用性を高める
- １つの大規模なリソースを複数の小規模なリソースに置き換えて、単一の障害点を作らない。
- キャパシティーを推測することをやめる
- 需要とワークロードの使用率をモニタリングして、リソースの追加と削除を自動化することで、プロビジョニングが過剰でも過少でもなく需要を満たせる最適なレベルを維持する。
- オートメーションで変更を管理する
- 自動化に対する変更も管理するために、インフラに対する変更はオートメーションを使用する。
パフォーマンス効率
- 最新テクノロジーを誰もが利用できるようにする
- 機械学習などの専門知識が必要なテクノロジはクラウドサービスを利用して、チームは製品の開発に集中する。
- わずか数分でグローバル展開する
- 迅速に世界中の複数のAWSリージョンにワークロードをデプロイできるので、最小限のコストでより低いレイテンシーとより優れたエクスペリエンスを顧客に提供できる。
- サーバーレスアーキテクチャを使用する
- 物理的なサーバーの管理が不要になる。
- より頻繁に実験する
- 様々なタイプのインスタンス、ストレージ、構成で比較テストを迅速に実行できる
- メカニカルシンパシーを重視する。
- クラウドサービスの使用方法を理解し、ワークロードの目標達成に最適なサービスを選択する。
コスト最適化
- クラウド財務管理を実装する
- クラウドの使用状態を管理し、コスト効率を高くするための知識を獲得する。
- 消費モデルを導入する
- 未使用時にはリソースを停止して、使用分のみ支払う。
- 全体的な効率を測定する
- ワークロードのビジネス効果とその実現に関連するコストを測定する。その測定値を元に、生産性の向上とコスト削減で得られる利点を把握する。
- 差別化に繋がらない高負荷の作業に費用をかけるのをやめる
- 物理サーバーの運用作業と、マネージドサービスを利用することでOSやアプリケーションの管理をやめる。
- 費用を分析し帰属関係を明らかにする
- システムの使用状況やコストからROIを把握し、リソースを最適化してコストを削減する。
サステナビリティ
- 影響を理解する
- クラウドワークロードの影響を計測し、ワークロードの将来の影響をモデル化する。KPIを作成し、影響を抑えながら生産性を向上させる方法を評価して、提案された変更による影響を見積もる。
- 持続可能性の目標を設定する
- トランザクションごとのコンピューティングリソースやストレージリソースの削減など、クラウドワークロードごとに持続可能性の長期目標を立てる。
- 使用率を最大化する
- リソースの使用率を最大化する。また、アイドル状態のリソース、処理、ストレージを削除するか最小化する。
- より効率的なハードウェアやソフトウェアの新製品を予測して採用する
- より効率的なハードウェアやソフトウェアの新製品を継続的にチェックし評価する。また、新しいテクノロジーを迅速に採用できるように柔軟性を持った設計にする。
- マネージドサービスを使用する
- マネージドサービスを使用することで顧客間でインフラを共有し、リソースの使用率を最大化する
- クラウドワークロードのダウンストリームの影響を軽減する
- サービスを使用するために必要なエネルギーやリソースの量を削減する
感想
クラウドの基本的な考えに沿ったものなので、どれも違和感は感じなかった。
サステナビリティの設計原則の「クラウドワークロードのダウンストリームの影響を軽減する」は正直よくわからんかった。
参考
AWS Well-Architected Framework
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/welcome.html