こんにちは、上野です。
Japan APN Ambassador 2020に選ばれ、AWS中心としたクラウド関連の業務に取り組んでおります。
AWS関連で悩みがあれば一度ご相談ください!
今回は初投稿ということもあり、具体的なサービスの深掘りではなく、クラウド設計時のおおまかな考え方について私の考えを書いていきます。
私がオンプレミス環境のインフラ構築・運用を過去にやっていたこともあり、クラウド環境で「ここって全然考え方がオンプレミスと違うな~」と思うポイントがいくつかあるのでそれらをまとめます。AWSを前提に記載していますが、他のパブリッククラウドでも考え方は基本的に同じとなります。
クラウド設計時のポイント
まずは一覧で。後ほど深掘りしていきます。
- 責任共有モデル
- 認証・認可(IAM)
- コスト管理
- 拡張性
- 新規機能の追加
責任共有モデル
AWSも公式で提示している責任共有モデルです。
AWSを利用している方であれば知っている方も多いと思いますが、意外と設計ポイントとして抜けてしまうことも多い印象です。私としては、しつこいくらいにこの責任共有モデルを意識したほうが良いと考えています。
責任範囲=設計範囲にもなりますので、設計書としてどこまでを対象とするのが明確にすることで、設計も進めやすくなります。
サービスによって責任範囲が異なるため、サービスごとにどこが責任範囲なのかを常に意識することが重要です。たとえばEC2であればOSのパッチ管理は利用者になりますが、サーバーレスのLambdaであれば、OS部分のパッチ管理はAWS管理となり利用者側の管理は不要となります。
我々NRIネットコムのようなシステムインテグレーター(SIer)がAWSでシステム構築を行う場合は、AWS、SIer、お客様の3階層またはそれ以上になることもあります。
設計するときは常に、「自分達の責任範囲はどこなのか」を意識して進めることが重要と考えています。
認証・認可(IAM)
AWSリソースの操作は、基本的にはインターネット経由で行うことになります。AWS上で作成したIAMユーザーで操作を行いますが、このユーザーおよび付与する権限の管理を怠ると、不正アクセスなどの被害を受ける可能性があります。
AWSで認証・認可の管理を行うサービスであるAWS Identity and Access Management (IAM)ですが、IAM設計フェーズがあっても良いくらい一番重要な設計ポイントになると思います。一番重要なポイントですが、オンプレミス環境では無い考え方でもあるため、詳細に権限の設計をしないまま進んでしまうパターンも見かけます。
IAMの構造を簡単に整理しておきます。次の主要な4つの機能を理解することが重要です。
IAMユーザー
AWSの認証を司る機能で、AWSを利用する個人単位でユーザーを作成して管理します。ID・パスワードまたは、アクセスキー・シークレットアクセスキーの2タイプの認証方法があります。パスワードは長くて複雑なもの、MFA(多要素認証)を設定するのがセキュアにするポイントです。アクセスキーは極力使わない、可能であればIAMロール、使う場合は必要最低限な権限といったところがポイントになります。
IAMグループ
同一の役割を持つIAMユーザーをグループ化する機能です。ここはイメージ付きやすいかと思います。IAMポリシー(権限)グループ単位で管理、付与できます。
IAMポリシー
AWSリソースへのアクセス権限をまとめたものです。ポリシーはJSON形式で記述しますが、AWSが提供するビジュアルエディタによる選択式で作成も可能です。
IAMロール
AWSサービスやアプリケーションに対して一時的なAWSリソースの操作権限を与える仕組みです。たとえば、EC2に対してIAMロールを割り与えることにより、EC2上で実行するアプリはIAMユーザーのアクセスキーID・シークレットアクセスキーを設定することなく、そのEC2に割り当てられたAWSの操作権限を利用できます。
4つのIAM機能を使用したイメージは以下のとおりです。
必要最低限な権限(IAMポリシー)を設定して、必要最低限のIAMユーザーやIAMロールに付与するというのが鉄則になります。
特にIAMポリシーについては、実際に操作をしてみないと必要最低限なポリシーを見極めるのが難しい部分もあります。また、本番運用が開始するとIAMポリシーを変更しにくくなりますので、検証、開発段階からIAMのポリシーを見極めていくことが重要になります。
ユーザー、グループ、ロール、ポリシーの定期的な棚卸しや見直しも運用設計として定めるようにしましょう。
コスト管理
利用料が従量課金ということは、クラウドなのである意味当たり前の概念ですが、設計ポイント(特に運用)としては浅くなりがちなところです。
私が特に言いたいのは、運用開始後もコスト(利用料)の監視、最適化しましょう!というところです。
使った分しか料金がかからないと言うと良く聞こえますが、使った分だけかかってしまうので、場合によってはオンプレミス環境よりもコストがかかることもあります。
サービスごとの利用料を監視して異常がないかチェック、土日や深夜にEC2を停止する、AutoScaleの導入、Savings PlansやReserved Instanceの購入といった、コスト削減の対策は多岐に渡ります。
考えるポイントが多いため、オンプレミス環境よりもコスト管理は難しいと私は思っています。そのため、運用設計として、誰が(体制)、どうコスト管理、削減をしていくのか考える必要があります。
うまく対策できると、オンプレミスであったようなリソースの余剰コスト(使っていなくてもコストは同じ)は無くなり、より最適化できるので、設計時にきちんと考えることが重要と考えています。
拡張性
サーバーのスペックや台数の変更が(オンプレミスよりも)簡単にできるので、変更できる前提で設計しましょうというところですね。
コストと同じく、運用開始後もリソーススペックや台数の監視、最適化しましょう!と言いたいです。
たとえばEC2のインスタンスタイプ。一度構築時に決定したインスタンスタイプで、障害なく運用できていれば開始後は変更しないことも多いかと思います。インスタンスタイプを小さくすることでコスト削減になったり、インスタンスの世代(t2→t3など)を変更することでより高コスト効率になることもあるので、是非運用開始後もこういった変更を積極的にできる運用設計ができると良いと考えております。
そしてクラウドで強力な機能とも言えるオートスケール機能。EC2を使用している現場を見ていると、あまり積極的にオートスケール機能は使用されていないという印象を受けます。(私だけの印象かもしれません)
オンプレミス環境では、設定したサーバをそのまま使い続けるという前提になるため、オートスケールのようにいつ無くなっても良いというような前提で構築、運用するのが少しハードルが高く感じるのかなと推測しております。
素晴らしい機能だと思うので積極的に利用されると良いなと思っております。拡張性に優れているという点だけでなく、数を自動調整するという点で耐障害性にも優れていると考えています。
新規機能の追加
AWSの最新情報ページを見てもわかりますが、新機能、新サービスが日々出てきています。
設計のポイントとして言いたいのは、運用開始後も新機能を取り込む前提で設計しましょうという点です。
すべての新機能を取り込むのは、設計変更にもなってテストもあるし大変という声もあるかもしれません。
ただ、あまりシステム機能に影響を与えずに新機能のメリットを得られる場合もあります。
たとえば、昨年12月に発表されたEBSボリュームのgp3は、gp2から変更するだけで高パフォーマンスかつ低コストになります。もちろん最低限の動作確認は必要ですが、設計変更というような大幅な変更は不要です。
また、2019年に一般公開されたAWS Security Hubは、有効にするだけで AWS内のセキュリティ情報集約やコンプライアンスチェックを行うことができ、特に稼働システムに影響を与えるものではありません。
このように、影響も少なく新機能のメリットを得られる場合もありますので、積極的にチェック、取り込みを行ってほしいなと思います。
まとめ
クラウド環境の設計ポイントについて、オンプレミスとの比較を行いつつ紹介しました。 ざっくりまとめると、「責任範囲を明確にして、IAMちゃんと設計して、運用後のコストと変更管理を考えましょう!」です。
こういったクラウド時における設計の考えは、AWSのWell-Architected Frameworkにまとまっているので参考にしてもらうと良いと思います。
NRIネットコムはAWS Well-Architected パートナーにも認定されていますので、Well-Architected な観点で AWS環境を見てもらいたい等あれば、是非ご相談ください。
みなさまのクラウド設計の参考になれば幸いです。