AWSへ移行後の運用のポイントを解説する「AWSに移行した環境の最適化のススメ」の連載です。前回の「AWSへの移行と障害時の対応」では、AWSへの移行後に運用する上で考慮しなければならない障害のポイントをご紹介しました。
今回の「AWSへの最適化の考え方」では、AWSを最大限に活用するための最適化の進め方について解説します。
連載「AWSに移行した環境の最適化のススメ」
【1】 AWSへの移行と障害時の対応
▶【2】 AWSへの最適化の考え方
【3】 事例と構成例
AWS Well-Architected フレームワークからみる、最適化のための考え方
前回も解説したとおりITインフラの運用は、「障害の対策」と「コスト」のトレードオフの妥協点を探ることが重要です。これは、オンプレミスと同様にAWSを利用する上でも考えなければならないポイントとなります。ただ、オンプレミスと異なる点として、AWSは障害発生時の影響範囲を減らすために多種多様な機能（選択肢）を提供しています。
ではAWSにおいて、トレードオフの妥協点はどのように考えるのがよいのでしょうか？
トレードオフの妥協点を考える上で参考にしたいものとして「AWS Well-Architected フレームワーク」があります。
AWS Well-Architected フレームワークとは、AWSが様々なAWSユーザーのアーキテクチャ設計や検証を元に作成した、AWS活用のベストプラクティス集です。フレームワークでは、ソリューションのアーキテクチャを設計する際に、ビジネスのコンテキストに基づいて、「運用上の優秀性」「セキュリティ」「信頼性」「パフォーマンス効率」「コスト最適化」の5つの柱の間でトレードオフを行うと記載されています。
参考：AWS Well-Architected フレームワークについてのホワイトペーパー
重要なことは「AWSへの最適化の継続」
ここでポイントとなることは、ビジネスの要件は一定ではないということです。ビジネスの成長にあわせて要件が変化すれば、それに伴いトレードオフの妥協点も変化します。
また、AWSからも続々と新サービスや新機能が追加されており、障害対応のための選択肢も日々増え続けています。
つまり永続的に「最適」な状況は存在しません。最初から「最適」であることを追求する必要はないとも言えるでしょう。
重要なことは「最適化（シフト）を継続する」ことであり、これはAWSのベストプラクティスの考え方からも言えるのではないでしょうか。
AWSへの最適化の継続とは？
では「AWSへの最適化を継続する」こととは、具体的にどのようなことを実践する必要があるのでしょうか。
一つの解として、新しいサービスや機能を評価・導入し続けるということが言えます。
この「新しいサービス」とは、「最先端のサービス」の導入を検討するのではなく、「自社が未評価のサービス」を評価・導入し続けることです。
ビジネス要件の変化やトレードオフで残った課題点を注視し続けながら、未評価のサービスをどんどん評価して取り込んでいく。このサイクルを回し続けることが「最適化を継続する」ことと言えるでしょう。
次回は、「最適化の継続」について、ケーススタディによる構成例を紹介しながらより詳細に解説します。
連載「AWSに移行した環境の最適化のススメ」
【1】 AWSへの移行と障害時の対応
▶【2】 AWSへの最適化の考え方
【3】 事例と構成例
※本記事の内容につきましては2020年3月時点での情報です。
AWSの運用を最適化したい方にオススメ！
コストを3割削減した秘訣
MSP事業者に運用を任せっきりになっていたため、AWSの構成や設定・稼働状況などがブラックボックスに…。そんな状況の中、運用管理コストを最適化した方法をご紹介します。