こんにちは。
構築担当の下地です。
年末年始でAWS認定アソシエイトレベルの3つの試験に挑戦しまして、
AWS 認定ソリューションアーキテクト - アソシエイト Win！
AWS 認定デベロッパー - アソシエイト Win！
AWS 認定 SysOps アドミニストレーター - アソシエイト Lose・・・
という結果になりました。
3つの中でSysOpsはちょっと難しく残念な結果になりましたので、また挑戦してアソシエイト３冠を目指そうと思います。
というわけで今日はAWSネタで1つ書かせて頂きます。
目次
AWS Well-Architected Framework (W-A)
AWSには、「AWS Well-Architected Framework」という考え方があります。
公式のBlackBeltオンラインセミナーやAWS Summit 2018の動画などを見ていると、時々これについて語られる部分が出てきたので調べてみました。
AWS Well-Architected Framework、略してW-Aは、2015年のAWS re:Inventにて発表されました。
それ以降毎年何らかのアップデートがされています。
W-Aは「AWSがお客様と10年以上に渡り作り上げてきた、システムの設計・構築・運用のベストプラクティスの集合」です。
なので何らかのサービスというより、ノウハウ集な意味合いが強いかと思います。
簡単に言うと、AWSさんが「今まで色んなお客様と仕事してきた中で色んな経験してきたので、それを振り返って上手く行ったノウハウだけまとめといた！」という資料集です。
W-AのホワイトペーパーやAWSのソリューションアーキテクト、W-A認定パートナー、Well-Architected Toolなどによって提供されます。
W-Aの概要
W-Aはざっくり分けると以下のような内容になっています。
・クラウドにおける一般的な設計の原則
・Well-Architected フレームワークの 5 本柱
- 運用上の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
1つ1つ書くとこの記事だけではとても収まらないので、今日は「クラウドにおける一般的な設計の原則」の部分についてです。
クラウドにおける一般的な設計の原則
この章は、クラウド環境でシステムを設計する際のベストプラクティスが、6項目にわたって書かれています。
オンプレミス環境と比較して、クラウドではどのようにシステムを設計すれば上手く行くか？というノウハウになります。
日本語版を読んでみたのですが少し分かりにくい感じでしたので、英語版も合わせて読みました。
原則1 Stop guessing your capacity needs
「キャパシティの予測をやめます」
従来の環境では一度サーバなどの機材を購入し、システムを構築した後にリソースキャパシティを変更することはできませんでした。
しかし、クラウドではそれを解決できる可能性があります。
従って、クラウドでシステムを設計するときは、時間をかけてキャパシティを予測せずに、最初からスケーラブルな設計にしましょう。
必要な時に必要な分だけキャパシティを予約したり、自動的にスケーリングしたりできます。
そのため、AWSのサービスにはElastic(伸縮自在)という言葉が多く見られます。
原則2 Test systems at production scale
「本番で利用する規模でテストします」
システムをテストする際、従来の環境では本番と同じシステムを作ってテストするのは難しいものでした。もし本当に本番と同じ環境を作るとすると、同じ台数分のサーバやネットワーク機器を用意しなくてはなりません。
そこで、テストのときは本番に似た小規模な環境を作ってテストをしていました。
一方クラウドではオンデマンドで本番とまったく同じ規模の環境を用意できます。
加えて、一定期間その環境を利用した後にすぐ廃棄することができます。
コストも利用分のみです。
原則3 Automate to make architectural experimentation easier
「テストを簡単に行うため自動化します」
クラウドでは、インフラリソースをコード化(Infrastracture as code)することにより、システムを低コストで作成・複製できます。
これにより手作業によるコストを回避できます。
また自動化によって実行された変更を追跡したり、影響を調査して必要であれば以前のパラメタに戻すこともできます。
原則4 Allow for evolutionary architectures
「発展的なアーキテクチャを受け入れます」
従来の環境では、アーキテクチャの決定(この型番のサーバ使うなど)は、静的な1度限りのイベントでした。
ただ、ビジネスやそれを取り巻く環境は常に変化し続けるため、その要件を満たせなくなるかもしれません。
クラウドでは自動化によりいつでもテストが可能なため、設計変更のリスクを減らすことができます。
これによりAWS側の進化を享受することができます。
インスタンスなどは逐次世代が新しくなりますし、それらを含めた新しいアーキテクチャを利用するほうがお徳ですね。
原則5 Drive architectures using data
「データ計測に基づいてアーキテクチャを決定します」
クラウドでは、アーキテクチャの選択がシステムの動作にどのように影響を与えるかを示すログデータを収集することができます。
これによって、収集されたデータを元に、改善を継続的に行えます。
この点についてはオンプレ環境でもログ収集は可能ですが、AWSではCloudWatchを始めとする各種サービスとそれら連携によって、より簡易な仕組みでデータを収集・管理ができます。
原則6 Improve through game days
「本番で想定されるトラブルをあらかじめテストし、対策します」
定期的にゲームデーを開催し、本番環境でのイベントをシミュレートすることで、そのイベントに対処するための手順を改善したり、イベントに対処する運用チームの経験値を上げることができます。
ゲームデーとは「本番で想定されるイベントをテストすること」とのことです。
まとめ
改めて読んでみると、キャパシティ予測は不要など刺激的な内容もあります。
オンプレミスとクラウドでは色々と勝手が違う部分も多いので、それぞれ適材適所で使い分けられると、もっと効率の良いシステム設計ができそうです。
以上、お読み頂きありがとうございました。
