この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ちゃだいん（@chazuke4649）です。
本日よりオンライン開催中の、Developers.IO 2020 Showcase にて、クラウド最適化アセスメントサービスをご紹介しました。そのYouTube動画と、使用したスライド資料、そしてその際にいただいた質疑応答を本ブログにてご案内します。
なお、レポート内容の詳細やサービスについてのご相談がございましたらクラスメソッドの担当エンジニアが承ります。下記のフォームにてご入力ください。
セッション概要
Day1 10/23（金） 15:15-16:00
クラウド最適化アセスメントでは、Well-Architectedフレームワークレビューの実践支援として、「セキュリティ」「コスト」「可用性」「パフォーマンス」「運用」の5軸に対し、クラウド利用状況の把握と課題抽出を実施します。クラスメソッドが持つAWSの知見をもとにした改善レポートをご提示し、クラウド環境を最適な状態に導きます。セッションでは、実例を交えながらサービスのご紹介をします。
YouTube動画
スライド資料
実際に使用したスライド資料がこちらになります。
参考資料
公式ページTOP
AWS Well-Architected – 安全で効率的なクラウド対応アプリケーション
ホワイトペーパーは、このページ内に、HTML版とPDF版（日本語あり）で提供されています。
BlackBelt資料
サービス別資料 | AWS クラウドサービス活用資料集 の Well-Architectecd を参照
Q&A
質問１ W-A Tool・質問への理解・リスクについて
質問
W-A Tool は質問がざっくばらんでイメージが付かず、どういった基準でチェックすればよいのかわかりません。また、設問に対して一つでもチェックをつけないとハイリスクと診断されることもあり、いまいち使いこなせていません。どのように付き合っていくのが良いと考えますか？
回答
まず質問やベストプラクティスについて詳細に理解したい場合、W-A公式ページTOP から飛べる角柱ごとのホワイトペーパーをぜひ参照してみてください。W-A Tool に記載の説明よりさらに詳しく説明されています。
リスクに関して、リスクを許容するかどうかは利用者次第ですが、ハイリスクとされた場合にはそれが許容可能かどうかよく検討しご判断いただくのがよいです。リスクの程度によっては受容するという選択肢もあり得ます。リスクを把握することは重要です。逆に、すべてのリスクを排除するアプローチは現実的ではない場合が多いので、リスクベースアプローチに基づいてコストと効果のバランスを踏まえてご判断いただくのがよいかと思われます。
そしてTool との付き合い方のコツとしては、途中で随所にメモを残せるようになっているので、よく分からない項目がある場合は一旦「該当しない」で回答し、メモにその旨記載し、とにかく１度通してみることをオススメします。２周目にてそれらを掘り下げるなどの対応が可能です。
質問２ 可用性について
質問
可用性について、昨年発生した東京リージョンでのAZ障害で3AZにするのが望ましいと言われていますが必須なのでしょうか。例えば、アプリケーションのセッションなどはElasticashに外出しすれば2AZでも障害時に縮退運用可能だとは思うのですが、いかがでしょうか。
回答
構成によっては2AZで十分なケースもありますので必須というわけではないと思われます。利用するサービスごとの仕様やベストプラクティスを参考にいただくのがよいかと考えられます。
例えば、ALBは2AZが必須なので、リソースの切り離しができない可能性があります。ElasticSearch は3つの専用マスターノードを構成することが推奨されています。（2AZ環境で、一方のAZに2つの専用マスターノードがあったとする。そのAZで障害が発生するとダウンタイムが発生する。）
Elasticacheについては概ねご認識の通りかと思われます。
参考記事
質問３ ビジネス要件を考慮したKPIについて
質問
事例のお客様C社の「ビジネス要件を考慮したKPI」とは例えばどういったことを決めるのでしょうか？
回答
申し訳ありません。実担当ではないため具体的なKPIが何であったかをお伝えすることができません。一般的には、パフォーマンスや可用性に関するメトリクスをKPIに設定する場合が多いです。例えば、ランディングページからのサインアップ数や、ページのロード時間などです。
具体例としてNetflixの場合、以下のようにKPIを設定しています。
私たちは、最も重要な活動である視聴に非常に近い単一の指標を探しました。再生の開始（「再生をクリックする」という行為）に関連するサーバー側の指標には、予測可能なパターンがあり、UI /デバイス/サーバーの問題が発生したときに大幅に変動することがわかりました。Netflixストリーミングパルスが作成されました。「1秒あたりの開始数」を表す「SPS」という名前を付けました。（意訳）
引用元）SPS: the Pulse of Netflix Streaming | by Netflix Technology Blog | Netflix TechBlog
他、運用サイドがビジネスサイドと、システムの信頼性をどう評価するかについて会話したことがないケースがあります。この場合、ビジネス的にみて重要な指標、あまり重要でない指標は様々です。この目線を合わせることで、運用サイドの方々は、どのメトリックをクリティカルとし、どのメトリックを無視できるなどというような、メリハリのついた合理的なモニタリングが実現できる場合があります。
終わりに
クラウド最適化アセスメント発表時の資料や質疑応答をご紹介しました。ご興味のある方はぜひ気軽に問い合わせてみてください!
それではこの辺で。ちゃだいん（@chazuke4649）でした。
お申し込みフォーム
今回ご紹介した内容について具体的なサービス説明やご質問などありましたらフォームにお問合せください。担当者から折り返しご連絡いたします。
※個人およびフリーランスの方、弊社が競合と判断した企業様からのお申し込みはお断りをさせていただく場合がございます。あらかじめご了承ください。
7
