はじめに
最近、AWSの資格試験の勉強を始めました。
小ネタを数多くアウトプットして学習効率の最大化を図っていきたいと考えています。
AWS Well-Architected フレームワークの設計原則
AWS Well-Architected フレームワークとは？
公式の説明はこんな感じ。
AWS Well-Architected は、クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供しています。
出典：https://aws.amazon.com/jp/architecture/well-architected
設計原則とわたし
AWS Well-Architected フレームワークが推奨する、運用上の優秀性を実現するための設計原則があります。
私は現在AWS上でインフラ構築やDevOps的なことをやっていますので、これが実践できているか見ていきます。
ビジネス成果を中心にチームを編成する
チームがビジネス成果を達成する能力は、リーダーシップのビジョン、効果的な運用、ビジネスに沿った運用モデルから得られます。リーダーシップは、チームが最も効率的な方法で業務を行い、ビジネス成果を達成するようチームにインセンティブを与える適切なクラウド運用モデルを用いて、CloudOps の変革に全力で取り組む必要があります。適切な運用モデルでは、人材、プロセス、テクノロジーの能力を活用してスケールと生産性の最適化を実現し、俊敏性、即応性、適応性を通して差別化を図ります。組織の長期的なビジョンは、エンタープライズ全体にわたってステークホルダーおよびクラウドサービスや消費者に伝える目標に変換されます。目標と運用上の KPI はすべてのレベルで一致します。このプラクティスは、以下の設計原則の実装から得られる長期的な価値を維持します。
出典：https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/oe-design-principles.html
→ ❌ あんまりできない。
現在のチーム編成は目先のニーズを実現するためにその都度構築してきた結果なので、ビジネス成果を最大化するように設計されたものとは言い難いです。
もっと高い視座を持て、ということでしょうか。
オブザーバビリティを実装して実用的なインサイトを得る
ワークロードの動作、パフォーマンス、信頼性、コスト、健全性などを包括的に理解します。主要業績評価指標 (KPI) を設定し、オブザーバビリティのテレメトリを活用して、ビジネス成果の達成が脅かされている場合に情報に基づいた意思決定を行い、迅速に対処します。実用的なオブザーバビリティデータに基づいて、パフォーマンス、信頼性、コストを積極的に改善します。
出典：https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/oe-design-principles.html
→ ⭕️ 割とできているかも。
完璧ではないですが、できている部分もあります。
例えば、監視などはTerraform Moduleで標準化してます。
前記事書いたので、良かったらご覧ください。
タグ付けによるサービス単位でのコスト可視化もできてたり、SLOの監視もできています。
弊社のVPoTが作ったSLOの監視に関する素晴らしいスライドもあるので、ご紹介。
可能な場合は安全に自動化する
クラウドでは、アプリケーションコードに使用するものと同じエンジニアリング原理を、環境全体に適用できます。ワークロード全体とその運用 (アプリケーション、インフラストラクチャ、設定、手順) をコードとして定義し、更新できます。その後、イベントに応じてワークロードの操作を開始することで、ワークロードの操作を自動化できます。クラウドでは、レート制御、エラーしきい値、承認などのガードレールを設定することで、自動化における安全性を実現できます。効果的な自動化により、イベントへの一貫した対応を実現し、人為的ミスを最小限に抑え、オペレーターの労力を軽減できます。
出典：https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/oe-design-principles.html
→ ⭕️ できている
インフラはTerraformでほぼ100% IaC化できているんで、これは大丈夫じゃないかな。
自動的なオートスケーリングやアラートのSlack通知なんかもできています。
小規模かつ可逆的な変更を頻繁に行う
コンポーネントを定期的に更新できるように、スケーラブルで疎結合のワークロードを設計します。デプロイの自動化の手法と併せて、小さく段階的に変更していくことで、障害が発生した場合でも影響範囲を小さく抑え、迅速に復旧することができます。そのため、自信を持ってワークロードに有益な変化を加えられるようになり、一方で品質も維持し、市場の変化にも迅速に適応できます。
出典：https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/oe-design-principles.html
→ ⭕️ まあまあできている
厳密なマイクロサービスを採用してはいないですが、単一で巨大なモノリシックなアプリケーションがあるわけでなく、多少はサービス単位で分割した複数のワークロードが存在しています。
また、変更もTerraform Moduleのバージョンアップデートのタイミングで定期的に取り込んでますし、バージョン指定で元に戻すことも容易です。
新しいアラートの追加など、ビジネスニーズが生じた時にも迅速に修正できていますね。
オペレーション手順を頻繁に改善する
障害を予測する
運用上のイベントとメトリクスから学ぶ
オペレーション手順を頻繁に改善する: ワークロードを進化させるときは、オペレーションを適切に進化させます。運用手順を実施するときに、改善の機会を探します。定期的にレビューを実施し、すべての手順が効果的であり、チームに周知されていることを検証します。ギャップが見つかった場合は、手順を適宜更新してください。手順の更新について、すべてのステークホルダーとチームに伝えます。運用のゲーミフィケーションを行ってベストプラクティスを共有し、チームを教育します。
障害を予測する: 障害シナリオを進め、ワークロードのリスクプロファイルとビジネス成果への影響を把握することで、運用の成功を最大化します。こうしてシミュレートした障害に対する手順とチームの対応の有効性をテストします。テストで特定された未解決のリスクを管理するために、情報に基づいた意思決定を行います。
運用上のイベントとメトリクスから学ぶ: すべてのオペレーションのイベントや障害から学んだ教訓を通して、改善を推進します。チーム間と組織全体で教訓を共有します。教訓は、運用がビジネス成果にどのように貢献するかについてのデータやエピソードに焦点を当てたものである必要があります。
出典：https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/oe-design-principles.html
→ ❌ あんまりできない。
運用手順のドキュメンテーションはできていますが、定点的な見直しや改善ということはあまりできていないです。
少人数のチームなので難しいところはあるんですが、しっかりと戦略的に取り組んでいきたいですね。
マネージドサービスを使用する
可能な限り AWS のマネージドサービスを利用して、運用上の負担を軽減します。それらのサービスの操作に関する運用手順を作成します。
→ ⭕️ できている
これはできてますね。ECS on Fargateだったり、RDSだったり、Lambdaだったり。
理由がない限りはマネージドなサービスを利用してますので、運用上の負荷は下げられているはず。
まとめ
正直、AWS Well-Architected フレームワークの設計原則を満たすべく現在の運用を作ったわけでなく、試行錯誤の結果という側面が強くはあります。
ただ、こうやって見るとできているところも結構ありますね。
今後はもっとこの設計原則を意識した運用体制の構築を心がけたいです。