クラウド運用で起こるあるあるミスの対処法 オンプレと同じじゃ恩恵は受けられない?はじめてのクラウド導入“これ”に注意(1/2 ページ)

クラウド移行は企業にとって大きな挑戦だが、それはあくまでDXの始まりにすぎない。クラウド運用フェーズではオンプレミスとは違う注意点が数多く存在し、これを知るかどうかで真のDXの実現に大きな影響を与えるようだ。

» 2023年04月11日 08時00分 公開
[折笠丈侍ITmedia]

この記事は会員限定です。会員登録すると全てご覧いただけます。

 はじめてのクラウド導入でよく起きる“あるあるミス”を紹介し、どのように回避すべきかを紹介する本連載。第1回では「導入検討フェーズ」、第2回では「移行作業フェーズ」、第3回では「構築作業フェーズ」に焦点を当てて解説した。連載最終回となる第4回では「運用フェーズ」で気を付けなければならないポイントを解説する。

この連載について

本連載では、「Amazon Web Services」(以下、AWS)のようなIaaS・PaaSベースのパブリッククラウドサービスを導入するにあたって、「ありがちな誤解」や「つまずきポイント」とその「解決策」を、計画フェーズと移行フェーズに分けて解説する。クラウド導入検討の参考になれば幸いだ。

筆者紹介:折笠丈侍(ソニービズネットワークス株式会社 開発本部)

98年より大手・新興キャリア数社でインターネットアクセスサービスや法人イントラネットソリューションのテクニカルセールスに従事。2007年よりソニーグループ傘下のソニービジネスソリューション株式会社に入社し、法人向けICTソリューション全般の法人営業とマーケティング支援を担当。2015年より同社AWSサービスのプリセールスエンジニアとして営業支援やマーケティング企画支援を担当。現在AWS認定12資格全て保有。



あるあるミス1:オンプレミスとクラウドの違いを無視して運用

 オンプレミスのシステム運用では、物理的アセット(ラック、電源、空調、ネットワーク、ハードウェアなど)をユーザーが所有し、その設計や保守運用を自前で行う一方、クラウドではベンダーがインフラ運用を担うため、余ったリソースをアプリケーション管理やデータ保護、新たなデータ分析基盤の構築などの新規プロジェクトに振り分けられる。しかし移行と構築が完了しても、オンプレミスのときと変わらないシステム構成や考え方で運用を続けている企業も多い。

オンプレミスとクラウドで運用がどう変わる?

 具体的にオンプレミスとクラウドでのシステム運用では何がどう変わるのだろうか。前提条件に関して大きく変わる項目を示したのが以下の図1だ。

図1 オンプレミスとクラウドでのシステム運用の違い(出典:ソニービズネットワークス作成資料)

 オンプレミスとクラウドを比較した際、注目すべき違いは2つあり、1つ目が「オンプレミスでは自社の占有資産だったリソースが、クラウドでは他のユーザーとの共有サービスになる」点だ。2つ目が「クラウドでは複数のマイクロサービス同士をAPIで連携させる分散型/疎結合型のアーキテクチャが基本になるため、それまで、単一/密結合型アーキテクチャで運用してきたシステムをクラウドに移行する場合、設計や運用の考え方の転換、再設計などが必要になる」点だ。

 オンプレミスで可能だったカスタマイズや独自のセキュリティ設計がクラウドでは出来なくなるが、この点は複数のマイクロサービス同士をAPI連携させて同様の機能を実現するアプローチで対応できる。つまり、オンプレミスでは意識することが少なかった「サービス単位のAPI連携」「セキュリティ実装」(認証や認可の権限付与)などをクラウドでは意識する必要がある。

あるあるミス2:モニタリングやロギングを軽視

 クラウドサービスではモニタリングやロギングをはじめとする運用監視に加え、セキュリティやコンプライアンスに対応する機能がサービスとして用意されており、実装は機能を「有効化」するだけで済む。

 「Amazon Web Services」(以下、AWS)は約30のセキュリティやコンプライアンス関連のサービスがあり、基本的なログやメトリクスは無料または低価格で取得できる。セキュリティや運用要件に合わせてこれらのサービスから必要な機能をアクティベートすれば、オンプレミスでは導入ハードルが高かったSIEM(Security Information and Event Management:セキュリティ情報イベント管理)環境を短期かつ低コストで構成可能だ。AWSのサービスは現在200を超えるが、それらについても主要なメトリクスやログを無償あるいは有償で取得できる。使い慣れたサードパーティー製品の併用もできる。

 メトリクスとログの取得は運用の大前提であることから、クラウド導入と同時にモニタリングやロギングの機能を有効化するのがお薦めだ。AWSの場合、アカウント開設時に「AWS Cloud Trail」というAPIコールログ(サービス操作履歴)を記録するサービスがデフォルトで有効化される。このサービスは自動的に「Amazon Simple Storage Service」(Amazon S3:容量無制限かつ高耐久のオブジェクトストレージ)にAPIコールログを暗号化し保存される。このデータストアにアクセス制限を追加してデータをロックすれば、改ざん不可能な証跡として監査に使用できる。

 また、構成管理サービスの「AWS Config」を組み合わせれば、事前に定義済みの構成ポリシーから外れた変更や意図しない操作をリアルタイムで検知でき、必要に応じて意図しない変更を本来のポリシーに自動修正するシナリオも組み込める。

あるあるミス3:重要なイベントを見落とす

 オンプレミスの運用の際は、予算やストレージ容量の制約からモニタリングやロギングの対象を絞り込み、重要なイベントやインシデントを見落としそうになるということがよくある。これとは逆に、クラウドではメトリクスやログの取得が容易なために監視項目を増やし過ぎたりアラームの閾値を敏感に設定し過ぎたりして、「運用担当者のアラート疲れ」を招くことがある。これにより重要なイベントを見逃すことにもなるので注意が必要だ。

 防止策としては、取得対象のメトリクスやログの精査、優先度に応じた可視性の高いダッシュボードの作成に加え、アラート対象イベントの定義やアラート閾値の継続的な見直しが挙げられる。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ