AWSを正しく使いこなす指針【前編】
AWSに必須 コストやパフォーマンスを最適化する「6つの柱」とは?
AWSでシステムを設計、運用する際に欠かせないのが 「AWS Well-Architectedフレームワーク」だ。本稿では、AWSのベストプラクティスの6つの柱と設計・運用のポイントを解説
企業のデジタルトランスフォーメーション(DX)推進において、クラウドサービスの活用はもはや不可欠な選択肢となっている。中でも、クラウドサービス群「Amazon Web Services」(AWS)は、その多様なサービスと高い信頼性から世界各国の企業に採用されている。一方で、AWSのポテンシャルを最大限に引き出し、安全かつ効率的なシステム運用を実現するためには、確立された指針が必要だ。
そこでAWSから提供されているクラウド設計や運用の指針が、「AWS Well-Architectedフレームワーク」だ。AWS Well-Architectedフレームワークでは6つの柱に基づいて、AWSを利用するユーザー企業がクラウド環境を評価し、拡張性や可用性のあるシステムを構築するためのベストプラクティスを提示している。
「AWS Well-Architectedフレームワーク」の概要と6つの柱
併せて読みたいお薦め記事
AWSのベストプラクティス
AWS Well-Architectedフレームワークにおける6本の柱は次の通りだ。
- 運用上の優秀性(Operational Excellence)
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- サステナビリティ(持続可能性)
以下ではそれぞれの項目について、AWSのガイドラインがどのような項目を解説しているのかを紹介する。
運用上の優秀性
運用上の優秀性とは聞き慣れない言葉だが、AWSは公式Webサイトで次のように説明している。
運用上の優秀性とは、優れたカスタマーエクスペリエンスを着実に提供しながら、ソフトウェアを正しく構築する取り組みです。運用上の優秀性の柱となるのは、チームの編成、ワークロードの設計、ワークロードの大規模な運用、経時的な進化のためのベストプラクティスです。
簡単に言えば、システムやソフトウェアの開発時に、運用面も考慮するべきということだ。そのため企業や開発者は、開発の初期段階から運用時の手作業を減らし、ヒューマンエラーを防いでプロセスの再現性を確保する必要がある。具体的には次の取り組みによって実現する。
- IaC(Infrastructure as Code:インフラ構成をプログラミングコードとして管理する手法)
- 自動化されたデプロイ(展開)
- 効果的なモニタリングとアラート
- インシデント管理
- 障害からの迅速な復旧
- システムの継続的な分析と監視
- フィードバックによる改善サイクルの構築
- ナレッジの管理と共有
セキュリティ
セキュリティでは、AWSで安全なシステムを設計、運用するために必要な内容が提示されている。「強力なIDとアクセス管理」「データ保護と暗号化」など、設計のベストプラクティスを挙げる項目だが、ここではその基礎となる責任共有モデルを解説する。
責任共有モデルとは、AWSとそれを利用する側の責任範囲を明確にするための情報である。AWSで利用するサービスにおいてユーザーが設定する範囲は基本的にユーザーの責任であり、例えば以下のような項目を管理する必要がある。
- ゲストOSの更新やセキュリティパッチ適用などの管理
- アプリケーションの構成、運用
- ファイアウォールの構成やネットワークの設定
- データの保護や暗号化、整合性確保
一方でAWS側はクラウド環境のインフラ全体を保護して正常に稼働させる責任を負う。例えば次の通りだ。
- 災害対策や入退室管理を含めたデータセンター施設の物理的な保護
- 障害時も事業を継続できるようにするための電力や空調設備
- サーバ、ストレージ、ネットワーク機器などハードウェアの運用と保守
- 物理サーバにインストールされているホストOSの運用と保守
このように責任範囲を明確にすることで、AWSを利用する側の負担を軽減しつつ、セキュリティ管理をしやすくしている。利用するサービスによって具体的な項目は異なるが、セキュリティの柱を理解するための前提にこの責任共有モデルがあることを覚えておくと、ベストプラクティスを理解しやすくなるだろう。
信頼性
信頼性では、想定した設計が正しく機能し、かつ一貫してワークロード(処理やタスク)を実行するための、次の項目についてのベストプラクティスが提示されている。
- 可用性
- フォールトトレランス(耐障害性)
- システムの一部が故障や停止に見舞われた場合、予備の系統に切り替えるなどの方法で正常な機能を保つこと。
- ディザスタリカバリ(DR)
- 復旧メカニズムの自動化
- 容量拡張の自動化
特に、障害から回復し、サービスの中断を防止するシステムの能力が焦点となる。システムの回復力を高め、ビジネス継続性を確保することが目標だ。
パフォーマンス効率
パフォーマンス効率では、コンピューティングリソースを効率的に利用し、変化する需要や技術をシステムに継続的に組み込むため、以下の項目についてのベストプラクティスが提示されている。
- 適切なリソースタイプの選択
- スケーラビリティ(拡張性)
- サーバの運用や設定をベンダーに任せる「サーバレス」アーキテクチャの検討
- データストレージとネットワークの最適化
クラウドサービスは、サーバレスをはじめ多様なアーキテクチャを選択できる一方、その設計次第でパフォーマンス効率が変動する。メリットを最大効率で享受するために必要となるベストプラクティスを、この柱で学習できる。
コスト最適化
コスト最適化では、不要なコストを回避し、価値に見合った支出を実現するための以下のベストプラクティスが提示されている。
- 需要に応じたリソースのプロビジョニング(配備)
- コスト意識の高いリソース選択
- リザーブドインスタンス(予約によって割引されるインスタンス)やSavings Plans(一定期間の利用を約束することで割引を受ける料金プラン)の活用
- 不要なリソースの削除
- コストのモニタリングと分析
コストを最小限にして利益率を上げつつ、システムが求められる成果を出すためには、この柱の内容が不可欠となる。
持続可能性
持続可能性は、2021年12月に新たにフレームワークに追加された項目で、環境への影響を最小限に抑え、持続可能な社会の実現に貢献する設計に求められる以下のベストプラクティスが提示されている。
- エネルギー効率の高いリソースの選択
- リソースの使用率の最適化
- 廃棄物の削減
持続可能性についても、先に述べた責任共有モデルが定義されている。クラウドサービスベンダーは効率的な電力と冷却技術に投資し、エネルギー効率の高いサーバを運用する責任がある。
一方で、プロビジョニングされたリソースを最大限に活用したり、エネルギー効率の良いプログラミング言語やアルゴリズムを選択したりするのはユーザーの責任だ。AWSが示している持続可能性についての責任範囲は次のように分かれている。
- ユーザー
- データ設計と使用
- ソフトウェアやアプリケーションの設計
- プラットフォーム(実行環境)のデプロイとスケーリング
- データストレージ
- コード効率
- 活用とスケーリング
- AWS
- サーバ
- 冷却
- 水
- 廃棄物
- データセンター
- 構成材料
- 電力供給
後編はAWS Well-Architectedフレームワークが必要な理由を解説する。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社ビザスク] 製造業の新事業創出 成功の鍵は「タラレバ問題克服」と「3つの判断ポイント」 -
製品資料
[日本シーゲイト株式会社] 実験のやり直しを防止 研究データ基盤に求められる高可用性ストレージとは -
製品資料
[株式会社Leaner Technologies] もっと安く買えるのに…… 間接材購買で“コスト削減機会”を逃さないためには -
製品資料
[株式会社セールスフォース・ジャパン] フィールドサービスの熟練技術者が「AIエージェント」を求めている理由 -
製品資料
[株式会社グリーンフィールド・オーバーシーズ・アシスタンス] 基礎から分かる「就労ビザ」 アメリカ進出を目指すなら知っておきたい取得戦略
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
年収700万超エンジニアに共通するスキルと「もっと勉強すべきだった分野」
-
2
ソフトウェア開発組織の疲弊を防ぐ、AI駆動開発の「レビュー負荷軽減」実践事例
-
3
仮想化環境の死角を“未知の脅威”が狙う時代――新たな敵をどう見破るか?
-
4
「Salesforceのテスト自動化ツール」に関するアンケート
-
5
ITエンジニア1265人調査 生成AIを使い込むほど「人の確認」が重い理由
-
6
AI時代の競争力はデータ基盤で決まる 仮想化刷新を未来への投資に変える条件
-
7
脱VMwareか、継続か? 仮想化ソフト主要6製品の機能とスペックを徹底比較
-
8
全社標準Copilotに絶望? MS Copilotで問い合わせ6割減できた企業は何が違った
-
9
NVMeとはやっぱり違うCXL接続の「MS-SSD」とは何か?
-
10
9割が頓挫する「AI内製化」 差がついたのはツールより設計力
ホワイトペーパーランキング PR
-
1
登録セキスぺが語る「SCS評価制度」の舞台裏 星を取得すべき理由と対応のコツ
-
2
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
3
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
4
「人員を増やす」という選択肢はない 情シスが負の連鎖から抜け出すには?
-
5
「問題が深刻化しやすいプロジェクト管理」から脱却する方法とは?
-
6
AI時代の組織設計:「判断と責任」を人に残すための2つの原則とは?
-
7
防御側の「3つの前提」が崩壊 AI時代のセキュリティに必要な3つの転換とは?
-
8
AI活用を停滞させる「2:6:2の壁」を乗り越えるためのポイントとは?
-
9
生成AIで文書活用を進めるには? 効率化と安全性をどう両立する
-
10
OSSでは困難 100超のサービスを持つマネーフォワードが実践した統合監視術
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー