| 作成日 | 2020/01/28 |
|---|---|
| 更新日 |
AWS環境の運用管理の課題
AWS環境上に構築したシステムの運用管理について、これまでのナレッジを元に整理した課題が以下の内容になります。
各々の課題がどんなものか、そしてHinemosはどの様に解決するのかを紹介します。
監視
AWS環境の監視において考慮すべき点は、専用リソースの監視、クラウドのプラットフォームの監視、そして、クラウド操作ログの監視です。
1.AWS環境の監視の課題
AWS環境の監視の課題を1つ1つ解説します。
Amazon CloudWatch連携（専用リソースの監視）
AWS環境の監視にはAmazon CloudWatch（以下、CloudWatch）は必要です。しかし、それだけでは実際の運用要件を満たせず、何かしらのカスタマイズや、監視ツール・サービスとの連携・作りこみが必要になります。
まず、AWS環境ではほぼ確実にPaaS/SaaSを使用しますが、このリソース監視や管理には必ずCloudWatchが必要です。旧来の監視ツールだけでは出来ないため、この時点でCloudWatchを外す選択肢が無くなります。
次に、CloudWatchの課題の3点見てみましょう。
① CloudWatchでは、保存できる期間が固定です。そのため、それより長期間の保存要件が場合は、それを実現する仕組み（過去データを退避する処理）が必要になります。
② システム監視の視点でみると、AWSのリソースが生きている時のリソース情報が欲しい訳ではなく、業務カレンダとして「業務稼働時間帯」に監視のアラートを、「メンテナンス時間帯」にはアラートを抑制したい、という要望があります。しかし、CloudWatchだけでは業務カレンダを定義する機能はありません。
③ AWSに限らずクラウドが提供するモニタリングサービスは、OSの中のリソースはデフォルトでは対象外です。CPU使用率全体は取得できても、Linuxの場合のuser/sys/iowaitの割合は分かりません。もっと簡単な例でいうと、ディスクIO数は取得できても、ディスク使用率は取得できません。
殆どのクラウドサービスにおいて、OSの中か外かで責任分界点となっています。そのため、ディスクフルを検知したいといったシンプルな要件でも、デフォルトで用意された以上の準備が必要になります。
この3点を眺めてみると、旧来の監視ツールが扱う範囲がCloudWatchの課題であり、CloudWatchだけを使用する場合はユーザ側で何かしらの仕組みを用意する、という事が必要になります。
AWS Service Health Dashboard連携（クラウドのプラットフォームの監視）
AWSはクラウドとして提供された環境ですが、このAWSの提供するサービスが正常に動作していること、つまりクラウドのプラットフォームが正常に動作しているか監視する必要があります。
旧来のオンプレミス環境や仮想化環境では、物理的なサーバ機器やストレージ装置が手の届く範囲にあり、この機器を監視する事ができました。クラウドになると、クラウドの提供するサービスの正常性の監視が、これに該当します。
このクラウドのプラットフォームの監視が行えないと、システム障害を検知した際に、業務アプリケーションの問題か、クラウドのプラットフォームの問題かの切り分けが出来ず対応に時間がかかってしまいます。よって、これらの監視結果は、旧来のシステム運用と同様に一元的なイベントとして管理されるべきです。
AWSにおいては、AWS Service Health Dashboardがプラットフォームの正常性の情報を提供するサービスになります。このWebページを表示すると、どのリージョンのどのサービスが正常なのか、異常なのかが簡単に確認できます。AWS環境とは異なるサービスとして存在し、ユーザがRSS経由で独自で監視する必要があります。2019年8月23日のAWSの大規模障害では、AWS Service Health Dashboardには、その情報が正しく提供されておりました。
AWS CloudTrail操作ログ監視（クラウド操作ログの監視）
AWSは、インターネット環境に公開されたパブリッククラウドです。そのため、AWS環境変更については、プライベートクラウドよりセンシティブに監視が必要です。
例１：不正なログイン
予期せぬAWS Management Consoleへのログインは危険です。
例２：許可の無いEC2インスタンスの作成
リソースの追加は費用に直接的に影響が出ます。
例３：危険なセキュリティグループの変更
サービス開始後などにセキュリティグループが変更されることは、計画的実行を除きありえません。
この変更に伴いシステムが非常に危険な環境にさらされる可能性があります。
AWS CloudTrailには、AWSのAPI操作がすべてログとして記録されます。蓄積・保管だけでなく、影響度の高い操作は直ちにアラートを上げる必要があります。
2.HinemosによるAWS環境の統合監視
このAWS環境の監視の課題は、Hinemosのクラウド管理機能により、簡易に解決してAWS環境の統合監視が可能になります。
まず、CloudWatch連携については、Hinemosの通常の「リソース監視」の設定ダイアログから、監視したいリソース値の項目をプルダウンで選択するだけで実現します。選択した項目がOSから取得するものであればOSから、CloudWatchから取得するものであればCloudWatchのAPI経由でHinemosが自動的に取得してくれます。
また、HinemosにAWSのアカウント・IAM情報を登録するだけで、AWS Service Health Dashboardへの監視も自動的に開始します。GUI上からAWSのサービスの状態が簡易に確認でき、監視対象のサービスをユーザがGUI上で選択するだけで、あとは異常が発生した際に集約されたイベントの１つとして、AWSの障害を扱えることができます。
最後に、CloudTrailのログを取得し、また収集・監視する仕組みを簡単に構築できます。
このように、HinemosではAWS上の監視に関する課題は、オンプレミス環境を運用していた時と比べて特別な知識も必要なく、解決することが出来ます。
運用自動化
AWS環境の運用自動化において考慮すべき点は、変化する環境に自動対応する構成管理の機構です。
1.AWS環境の運用自動化の課題
AWS環境の運用自動化の課題の背景を解説します。
環境把握と環境変更への追随
柔軟なリソースコントロールができるAWS環境においては、その環境把握とリアルタイムでの環境変更による追随が重要です。まず、この理由を明確にしましょう。
① EC2インスタンスの検出
システムの運用基盤の初期構築時、EC2が数十台などある場合に、これを全て管理対象（監視やジョブの実行対象）として登録する必要があります。また、オートスケーリングの機構を使用している場合は、初期構築以外で管理対象のメンテナンスが必要です。
② リージョン、アベイラビリティゾーンへのマッピング
管理対象が具体的にどのロケーションに配置されているかは重要です。例えば、アベイラビリティゾーンの障害があった際には、影響範囲を早急に把握する必要があるからです。
③ VPC、サブネットへのマッピング
ネットワーク構成の把握も重要です。特にセキュリティの観点で、どことどこの間が通信可能かといった事を運用側でも把握します。これにより、トラブル発生時の対応が早急に行えます。
これは、これまでのオンプレミス環境や仮想化環境では存在しなかった運用タスクです。これを人手で実行しようとすると、それが100%運用コストの増大に繋がります。
監視・ジョブの運用自動化
変更された環境に対する監視・ジョブ運用を自動化（無人化）する為には、次の３ステップに分けた自動化が必要です。
① 自動検出
まず、管理対象のEC2インスタンスがどのリージョン、AZ、VPCに存在するかを把握する必要があります。そして、オートスケールや計画的な仮想マシンの追加・削除といった環境変更を自動的に検出する仕組みが必要です。
実はこの変更を管理するというのは非常に準備が掛かります。これは常に最新のシステム構成の情報（リポジトリ情報）を保持していることが前提になり、変更が行われた際に、どこが減ったのか・増えたのかという差分を確認することで必要となるからです。
② 自動識別
EC2インスタンスの増減を検出しただけでは何も出来ません。検出した対象が何者か（OSは何か、WebサーバやAPサーバの機能を持たせたEC2か）といった識別する仕組みが必要です。
当たり前ですが、WebサーバにはWebサーバ用の監視とジョブを、APサーバにはAPサーバ用の監視とジョブを実行したいからです。
③ 監視・ジョブの自動開始・停止
検出したEC2インスタンスが何者か識別出来ると、それに対してどんな監視やジョブを実行するかが決まります。
そこで初めて、識別したものに対して、しかるべき監視やジョブを自動的に行う仕組みが必要になります。
これは、これまでのオンプレミス環境や仮想化環境では存在しなかった運用タスクです。これを人手で実行しようとすると、それが100%運用コストの増大に繋がります。
このAWS環境の変更に対する監視・ジョブ運用の「自動化」は、必須の要件です。AWS台頭時に本当にあった話ですが、パフォーマンス向上に向けたEC2インスタンスの追加に対して、監視対象として手順で追加するのが漏れてしまい、運が悪くそのEC2インスタンスに障害が発生してしまい、検出が遅れたことでサービスに影響を出してしまったという事例もありました。
つまり、人手による環境変更の運用対応は限界、それがAWSのリソースコントロールの柔軟性の高さが示すものです。
2.Hinemosによる運用自動化
このAWS環境の運用自動化の課題は、Hinemosのクラウド管理機能により、簡易に解決できます。これを解決する、具体的な機能を紹介します。
自動構成管理
HinemosにAWSへの接続情報(AWSアカウント、またはIAMユーザ、IAMロール)を登録すると、AWS上のEC2インスタンス情報を自動的に取得し、リージョン、アベイラビリティゾーン、VPC、サブネットの単位で自動グルーピングします。運用開始後も自動追尾して、環境変更時に伴う運用操作は必要ありません。
例え、EC2インスタンスが100台、200台あろうと、ユーザが行う手順はAWSへの接続情報を登録するだけになります。
タグとルールを使った自動識別
EC2インスタンスにKey,Vlueのタグ情報を付与することが出来ますが、Hinemosではこれを使ってEC2インスタンスがWebサーバなのか、APサーバなのかといった識別をします。Hinemosは自動的にタグ情報からその対象を識別して、WebサーバのEC2インスタンスならEC2のスコープ（グループ）、APサーバならAPサーバのスコープ（グループ）に割り当てます。もちろん、複数の属性（Webサーバ兼APサーバ）といった指定も出来ます。またIPアドレスやコンピュータ名からスコープ割り当てを行うルールの設定も可能です。
スコープを使った監視・ジョブ設定
ここまでで監視やジョブを自動実行する仕組みは完了しています。これを実現するのはHinemosの根幹と言えるリポジトリ機能です。
Hinemosは管理対象の1つ1つをノードと、それをグループ化したものをスコープと呼びます。スコープは、WindowsやLinuxといった予め用意されたものの他に、ユーザが任意で作成できます。そして、Hinemosの最大の特徴は、監視やジョブの対象に「スコープ」を指定できる事にあります。つまり、PING監視をLinuxノード10,000台に対して実行したい場合でも、PING監視設定を1つだけ作成して、実行対象にLinuxスコープを指定すれば完了です。
予め、Webサーバ用の監視設定とジョブ定義をWebサーバ用のスコープにしておけば、あとはHinemosが自動的にWebサーバのEC2インスタンスを検出・識別してくれるので、自動的に監視とジョブが動作させる事が出来ます。
この機能のポイントは、運用設計者はWebサーバに対してどんな監視をしたい？ジョブを実行したいという論理的な世界で設計し設定を作成すればよく、実際に何台のどのEC2インスタンスがWebサーバか、はHinemosにお任せして運用できる点にあります。
このタグを使った自動識別は、AWSを導入した初期のプロジェクトメンバから要望があり実現したものです。つまり、現場が今すぐに使いたい機能です。実際にこの機能を活用し、運用をほぼ無人化したプロジェクトもあります。コスト削減のため、毎朝EC2インスタンスを作成して業務処理を実施します。そして、夜になるとEC2インスタンスを削除する。そういった環境に対する監視や業務ジョブの実行について、上記の機能を使うことで毎日の環境変更における運用作業がゼロになりました。
リソース制御
1.AWSのリソース制御の課題
AWS環境のリソース制御の課題の背景を解説します。
AWS Auto Scalingの課題
AWS Auto Scaling は非常に有用なソリューションですが、必ずしも全てのプロジェクトで利用される訳ではありません。その理由を聞くと、スケールイン・スケールアウトのトリガーの条件設定が設計時点では難しく、試験だけで問題をクリアに出来ず（または試験が出来ないというケースも）、運用後のチューニングが必要になるという点にありました。予期せぬタイミングでトリガーが発動するかもしれない、しかもそれが費用にダイレクトにかかってくるという問題にも繋がります。
サービス開始後もSEがメンテナンスできる体制があれば良いですが、SEが設計して運用はオペレーターが実施する日本の体制では、こういった日々のメンテナンスは避けたい点として挙げられます。
そのため、単純に負荷の低いタイミングではEC2インスタンス停止させておいて、必要に応じて起動・停止だけするプロジェクトもあります。
リソース制御と業務連携
しかし、EC2インスタンスの起動・停止のコントロールは単純に実施すればよいものではありません。基本的に、業務・システムと連動して行われます。例えば、EC2インスタンスを停止する前処理としてネットワークの閉塞やアプリケーションの停止を、後処理としてバックアップ（スナップショット）の取得といったものがあり、これをスケジュール的に起動し、監視の無効化・有効化といった業務カレンダに伴った制御が必要になります。
つまり、システム運用の中においては、EC2インスタンスの起動・停止といった簡単な処理でも、業務フローと連携する機能が必要になります。単純にEC2を起動・停止するだけのサービスなどはたくさん存在しますが、結局はそれ以外の部分の作りこみにコストがかかります。
2.リソース制御と業務連携
このAWS環境のリソース制御と業務連携の課題は、Hinemosのクラウド管理機能により、簡易に解決できます。
AWSリソース制御ジョブを簡単作成
HinemosではEC2インスタンスの起動・停止ジョブをGUIから作成できます。対象をノード単位でもスコープ単位かで指定し、起動や停止、スナップショット作成の処理を選んで、といったウィザード形式で進めるだけで、既存のジョブフローに当該処理を組み込めます。そのため、AWS CLIを使ったユーザの作りこみ作業が不要になります。
ジョブ管理機能による業務連携
そして、Hinemosの強みであるジョブ管理機能により、ジョブフローを業務カレンダに従いスケジュール実行管理が可能です。EC2インスタンスといったサーバのレイヤではなく業務ジョブというレイヤで、複数のEC2インスタンスを跨って俯瞰的に管理出来ます。 世の中には監視ツール・サービスは有象無象ありますが、ジョブ管理を持つ製品、そしてクラウドに対応した製品は数少ないです。
3.HinemosによるAWS使用料金の削減
このリソース制御の根本にあるのは、AWS使用料金を如何に削減できるか、といった点にあります。感覚的に理解している方も多いと思いますが、これを数値化するとよりその必要性が理解できると思いますので、順に解説します。
まず、AWSの、主にEC2インスタンスの使用料金はEC2の起動時間になります。
次に、EC2インスタンスを計画停止した場合の削減効果を数値化してみます。24時間365日稼働するシステムと比べて、社内限定利用など利用頻度に応じて停止時間できるケースがあると思います。
① 土日を停止できれば
月曜から日曜の1週間、つまり7日間のうち、土曜日曜の2日を停止する事を考えます。すると、EC2インスタンスの利用料金は単純計算で5/7、つまり約70%のAWS使用料金で済みます。
② 土日＋営業時間の8時～24時に限定できれば
これに追加して＋営業時間の8時～24時に限定できた場合、8時～24時は24時間中の16時間に該当するので、土日停止(5/7)×営業時間(16/24)で約50%のAWS使用料金で済みます。
これを実際の費用で考えると、毎月100万円のAWS使用料金が掛かっていたところを、月約50万円に押さえることが出来るようになります。実際にAWSを初めて導入したプロジェクトが、オンプレミス環境の時を同じ感覚でAWSを使用してしまい、オンプレミス時代よりもかえって費用が高くなったという話をよく聞きます。実際にAWSをそのような使い方をすると、コストメリットが全く出ないという人も現れています。
これと全く同じケースではないのですが、Hinemosでリソース制御した環境としなかった環境のコストを実際に計測してみた図が以下の通りです。赤色と比べて青色のコストが非常に高いことが確認できます。
課金管理
AWS環境の課金管理において考慮すべき点は、システム構成との紐づけと管理を誰が行うか、という点です。
1. AWSの課金管理の課題
課金管理のサービス・機能は進化続けていますが、ここでは基本に立ち返って、本質的な課題は何かを抑えてみたいと思います。
課金アラートの限界
多くの人が見かけるのが、（少し古いですが）次の課金アラートの仕組みだと思います。アカウントやサービスの単位で最新の金額で見える化とアラートが可能です。気づきという点では重要ですが、不要なコストを削減するための分析には情報が不十分です。
課金配賦管理の限界
もちろん分析のための機能は追加されていますが、一番の細かな情報としてはCSV形式で出力される各リソースの時間単位の課金情報になります。全てを開示してくれているので後はユーザ側で、という考え方も出来ますが、これが非常に複雑であり運用に限界がきます。
① タグ管理
まずこのCSV情報はタグ管理をする前提にあります。AWS運用はタグ運用と言われるほど、タグが重要です。しかし、ここではかなり細かな部分まで管理が必要です。例えば、1つのEC2インスタンスの金額をこのCSVから判断しようとすると、複数の項目を合算する必要があります。また、アタッチしているEBSも別リソース扱いのため、どのEC2とどのEBSが関連するかもユーザ管理になります。
② システム構成とのマッピング
ここで最も本質なのが、ユーザが見たいのはシステム構成の単位、例えばWebサーバ群やAPサーバ群でどうか、といった形で値を見たい訳です。なぜなら、その単位で設計を行い監視やジョブ実行などを制御するからです。これに対して、Auto Scalingといった歩率的な増減の対応や、システム構成に関するタグ付けなど、考慮すべきものが多くあります。
1つ1つはシンプルな課題ですが、この数が多くなり、そして構成変更を伴う日々の運用の中で実施するとなると、無視できない稼働が掛かることになります。本質的にはAWSだけではなく、パブリッククラウドサービスにおける課金管理の課題になります。
2.HinemosによるAWS課金配賦管理
このAWS環境の課金配賦管理の課題は、Hinemosのクラウド管理機能により、簡易に解決できます。
Hinemosでは他の監視機能と同じUIで設定可能な簡易課金アラートの機能の他に、AWSの提供するCSVをタグに従って自動集計し、サーバ・システム単位での利用状況を可視化する課金配賦機能を備えています。
サーバ・システム単位での課金アラートから、日単位の料金の増分表示など、様々な課金管理を実現する機能があります。
クラウドが提供する視点での管理ではなく、Hinemosが持つリポジトリ＝システム構成情報を活用し、運用者の視点での課金管理が可能になります。
OSサポートレベル
これまでの監視やジョブといった観点とは違った視点で、AWS環境のOSサポートレベルに関する課題に触れてみます。
1.OSサポートレベルの課題
AWSの提供するAmazon Linux2、当初はライトなユーザが利用すると想像していましたが、実はセキュリティ意識の高いお客様が積極的に導入されるケースが増えているのが見えてきています。
OSのセキュリティ対応
Red Hat Enterprise Linux等の商用OSについては、OSのアップデートやセキュリティパッチの入手が、オンプレミス環境より、クラウドの方がワンテンポ遅くなります。AWSの問題というより、パブリッククラウド全体の問題であり、クラウドベンダ毎に様々な取り組みが進められています。
Amazon Linux2とJavaサポート
AWSにおいて前述の問題を解決する1つが、Amazon Linux2です。AWSの中で最も早くセキュリティ対応が行われるOSとして、金融機関などでも採用の話を聞きます。
しかし、ここで「Amazon Linux2に対応した運用管理製品」と「Java」の2つの問題が出てきます。
① Amazon Linux2に対応した運用管理製品
これから新規で構築するシステムなら、そのOSで動作させるアプリケーションをどうするかの設計をすれば良いだけの話です。これはシステムのメインをつかさどるアプリケーションだからこその立ち位置です。
変わって運用管理でいうと、システムを支えるもののため、様々なOSに対応している必要があります。しかも管理対象としてではなく、運用管理マネージャ機能やそのクラスタ構成といった自身が動作するOS・環境として対応していないと意味がありません。その環境だけ、Amazon Linux2の恩恵を得られなくなります。
② Java
Amazon Linux2上で動作させるJavaは何にするかといった点も問題があります。未だにエンタープライズ向けのアプリケーション・ミドルウェアはJavaで動作するものが多くあります。
Red Hat Enterprise Linuxと同じOpenJDKを、という方がいるかもしれませんが、実はあれもRed Hatがディストリビュータとして公開・サポートするOpenJDKのため、OpenJDKのプロジェクトが公開しているものと厳密には差があります。例えば、バンドルされる証明書が異なっているため、Red HatのOpenJDK上ではAWS SDK for Javaは動作するが素のOpenJDKのビルドパッケージだとAWS SDK for Javaが動作しない（通信が繋がらない）、といった具体的な事例もあります。
これを解決するのがAWSの提供するJavaのAmazon Corretであり、運用管理製品がJavaで動作する場合には、これに対応していないと、Amazon Linux2の運用管理が行えなくなります。
2.Hinemosの動作対応環境
HinemosはAmazon Linux 2オンリーで構築されたシステムの運用管理も可能です。
Amazon Linux 2対応
Hinemos ver.6.2より、管理対象（Hinemosエージェントの動作するOS）としてだけでなく、Hinemosマネージャの動作環境として対応しました。もちろん、クラスタ構成を組むミッションクリティカル機能にも対応しています。
Amazon Corret対応
HinemosはJavaで動作するプログラムになっていますが、Javaランタイム環境としてもAmazon Corretに対応しています。
管理対象だけでなく、マネージャ機能が動作しクラスタにも対応するジョブ管理製品はHinemos以外に殆ど存在しないと思います。
関連情報
お問い合わせ
