はじめに
普段数多くの設計書や構成のレビューをしていますが、その観点ってなにがあるんだろう？とふと思ったので、普段頭の中で考えているレビュー時の観点をアウトプットしていこうと思います。
これで全部というわけではないと思いますが、参考になれば幸いです。
※多少AWSベースとなっていることはご留意ください。
簡単な自己紹介
職業：AWSメインのクラウド基盤のエンジニア。たまにAzure、GCPも。（一応どちらもPro相当の資格を保持しています。）パブクラへの移行に関するコンサル、基盤設計、構築など色々やってます。
AWSはTop Engineers(Service)、ALL Certificate Engineers（昨年11資格を取得したので）に認定されてます。
要件定義時/提案時
- お客様はなぜクラウドに移行・利用したいのかの理由、目的を抑えているか
- お客様の実施したいことが、記載されている要件で実現可能か
- 要件に対して、クラウドのベストプラクティスを反映した提案ができているか
- 記載内容に実現不可能なことや矛盾はないか
- 非機能要求グレードの内容に対して要件が定義できているか
- アプリケーションのモダナイズやクラウドに最適化した構成を取ることを意識した要件になっているか
まずは、要件定義や提案時の観点です。
上記に記載している通り、一般的なレビュー観点が多いですが、クラウド観点で意識することも多々あります。特にお客様はなぜクラウドを利用したいのかという点をヒアリングし、その目的がクラウドで達成できるのか？という点を明確にしなければなりません。単純にコストを低減させたいなのか、クラウドを利用することで、迅速なデプロイを可能とし、イノベーションにつなげたいのか、信頼性を向上させたいのかなど目的を明確にする必要があります。例えば、単純にコストを下げたいという目的でクラウドを選定しても、構成によってはむしろオンプレミスのほうが安価に済んでしまうこともあります。また、お客様ができるだけモダンなアプリケーションにしたい（コンテナやサーバレスなどの活用）といっても、そのメリットをお客様が受けうる運用をしなければ、移行に多額の費用がかかるだけで、そのメリットは大幅に減ることでしょう。クラウドエンジニアがここでやらなければならないことは、「クラウド移行の目的を把握すること」、「その目的に対して適切な要件や提案を行うこと」、「必要に応じて、クラウドのメリットやベストプラクティスをお客様に説明し、お客様がやりたいことを一緒に作っていくこと」なのかなと思います。お客様の中にはなんとなくクラウドにしたら安くなると思っていたという方や、上に言われて使わなきゃいけないんだけどよくわからないという方も多々見られます。その中で、クラウドエンジニアは、お客様が本当にやりたいことを見つけ出し、必要に応じてクラウドに合わせた業務改善や、運用を提案する必要があります。
また、クラウドに移行するのであれば、アプリケーションのモダナイズは避けて通れない部分です。
お客様の運用や予算でははまらないケースは見極めが必要ですが、モダナイズ観点では以下の観点で見ることが多いです。
- マイクロサービスやサーバレスを意識した構成となっているか
- クラウド側で提供しているマネージドサービスを活用しているか（仮想マシンでの管理は極力避ける）
- クラウドのメリットを最大限活かす構成となっているか（例えば、AutoScalingなどによる、従量課金のメリット等）
- アプリケーションやインフラのデプロイを自動化する構成となっているか
基本設計時/詳細設計時
- 要件定義書に記載された要件を満たすクラウド構成となっているか
- クラウドのベストプラクティスに基づいた構成になっているか
- 主にWell-ArchitectedFrameworkの観点でRVしますが、代表的なものを以下記載
- インスタンスタイプなどは運用の中で柔軟に変えていくことが前提ではあるが、余裕を持った選定をしていないか（クラウドではリソースは可変的に利用できるのでギリギリをせめてよい）
- IaCでのコード管理とデプロイの自動化ができているか
- クラウドベンダの提供するセキュリティ製品を活用する事ができているか
- インシデント発生時の通知や対応が設計できているか
- マネージドサービスを活用した構成となっているか
- 要件に対して過剰な構成をとっていないか（例えばSLA等でマルチリージョンにするのかマルチAZでよいのかなど）
- 変更することを前提とした設計になっているか（サービスのアップデートに追従できる運用を確保しているか）
- サブネットやセキュリティグループが適切に分離されているか
- ゼロトラストを基本とし、すべてのレイヤーで暗号化、認証が行われているか
- 最小権限の原則で権限が適用できているか
- アプリケーションの正常、異常を適切に判定し、回復までを適切に設計しているか
- ・・・・などなど
基本、詳細設計のレビュー時に考えることはかなり多いです。レビュアーの知見に依存してくるところは多いですが、AWSで提供しているWell-ArchitectedFrameworkを参考にするのがよいでしょう。レビューツールも提供されているので、質問に回答する形式で、設計内容を見直してみるとよいです。
また、設計者によってはオンプレミスの知見ベースで設計を行っていることもあり、オンプレミスとクラウドとの間での考え方の違いを意識した観点をより注力してもよいでしょう。
パラメータ定義
いわゆる各種サービスのパラメータ設計の観点です。
- 基本、詳細設計書に記載された要件を満たすクラウド構成となっているか
- 基本、詳細設計書に記載されていない部分の設計内容が適切か
- 設計内容に技術的な誤りはないか
これはシンプルです。実際にサービスを利用する上での設定値の定義となるので、必要に応じて実際にコンソールを触って、設定内容が網羅的に記載されていること、設計内容が基本、詳細設計書に記載されている内容を満たしていることを確認すればよいです。また、基本、詳細設計書に記載されていない部分に関しては、内容にもよりますが、設計根拠が適切かどうかを確認する必要があるでしょう。必要に応じてアプリケーションの仕様や、運用方法を確認し、適切な設定値を選定する必要があります。
まとめ
普段意識しているであろうことを思いつく範囲ではありますが記載してみました。
結構色々意識することが多いですね。
レビュワーとしてはレビューの目的を意識したいものです。レビューによって、よりお客様にとってメリットのある構成となることが大切ですので、レビュー前の構成より、セキュリティが向上した、コストが下がった、可搬性が上がったなどの効果がでると嬉しいですね。このレビューは１度きりではなく定期的に実施することをおすすめします。クラウドサービスは大変アップデートが多いものですので、レビュー時にはできなかったことが、次のレビュー時では実現しているかもしれません。１日前はこの構成が最適だったのに、このアップデートのおかげでこっちのほうがいいよねなんてことも・・・
レビュアーの立場としてはしっかり情報をキャッチアップして、情報を展開してあげることも意識したいものです。