■クラウドでの一般設計原則
AWS Well-Architected Framework の説明の前に！
- 必要なキャパシティを勘に頼らない
- 本番環境でのシステムテストを行う
- アーキテクチャ試行の回数を増やすために自動化を取り入れる
- 発展的なアーキテクチャを取り入れる
- データ計測に基づいてアーキテクチャを決定する
- 本番で想定されるトラブルをあらかじめテストし、対策する
■AWS Well-Architected Framework とは
アーキテクチャーの評価、改善のためのフレームワークです。
設計意思決定がどのようにビジネスに意思決定するのか？
５つの柱（観点）に分けて設計の原則、レビューするための質問事項を整理した資料です。
例えば、セキュリティ対策ってどこまでやったらいいの？とか難しいところだと思います。
やるとキリがない！
そこで、AWS Well-Architected Framework を利用することで判断することができます。
■５つの柱とは
- セキュリティ
- 信頼性
- パフォーマンス効率
- コストの最適化
- 運用上の優秀性
では、一つ一つ見ていこう！
■セキュリティ
- IAM
- 検出制御
- インフラストラクチャの保護
- データの保護
- インシデントの保護
認証の仕組みといったIAM、どういう風に侵入や問題が検出されるかといったことに対しての制御や保護、万が一何か起こってしまったときにどう対応するかといった点がポイントです。
では、設計していくときに、
- 強固な認証基盤を整備する
- 後から追跡できるようにトレーサビリティを有効にする
- すべてのレイヤーにセキュリティを適用する
- ベストクラティスを自動化する（できるだけ手動をやめる）
- 転送データ、保存データともに保護する
- できるだけデータにはアクセスできない権限にする
- 万が一に備える
■信頼性
- 問題、障害から復旧する
- ベストクラティスを適用する
- 障害を予測、対応、防止する
可溶性を高めるという点はもちろんですが、万が一何か起こったときに適切に復旧できる、万が一を起こさないようにするための予測をするという点がポイントです。
では、設計していくときに、
- 回復手順をリハーサルする
- 障害からの回復を極力自動化する（手作業によるミスを防ぐ）
- 冗長化する
- キャパシティ予測をやめる
■パフォーマンス効率
- カスタマイズ可能なソリューションを選択する
- 継続的な革新のためにレビューし、AWSのサービスでモニタリングする
継続的な革新とは、今手動で行っているものも未来ではAWSの新しいサービスとして提供されるかもしれません。その場合は手動による運用上のコストがなくなり、効率が上がります。
では、設計していくときに、
- 最新技術を積極的に導入する
- グローバル化を即座に実行する
- サーバレスアーキテクチャを用意する
- 試行の回数を増やし、最適な技術を選択する
■コストの最適化
- コスト効率の高いリソースを利用する
- 需要と配給の一致
- 支出の認識を高め、最適化する
では、設計していくときに、
- 従量課金の導入
- TCOツールを活用して予算を予測する
- データセンタ運用のため投資をやめる
- 見えないコストを分析し、マネージドサービスを利用して、所有コストを低減する
■運用上の優秀性
- 変更管理の自動化
- イベントに対応する
- 標準を定義する
では、設計していくときに、
- 運用をコード化する
- ドキュメントに注釈をつける
- 頻繁に運用手順を見直し、障害を予測し、失敗を改善に役立たせる
Well-Architected Guidance Engine
AWS Well-Architected Guidance Engine がAWS Control Tower で利用可能に
- 質問と回答に基づいて、コンソールで規範的ガイダンスを受け取ることができます。
- Control Tower が利用できるリージョンで利用できる必要がある。
- Control Tower は推奨設定に基づくAWSアカウントを数クリックで立ち上げるサービスです。