コラム

はじめに

こんにちは、クラウドCoEの熊谷です。
先日城前が「マルチアカウントで構成管理情報の自動収集を行う(AWS)」をブログで紹介しました。

マルチアカウントで構成管理情報の自動収集を行う(AWS) | BTC Cloud (bigtreetc.com)

早速城前の手順に従って、実際にお客様環境にインベントリ収集機能を導入することになりました。
今回のブログでは、その際に発生したトラブルとトラブルシューティングの方法を2部構成でご紹介したいと思います。
1本目の今回は、SSM Inventoryの構成を解説し、トラブルシューティングの為に必要な知識を整理します。

構成（ユーザーが設定する箇所のみ）

城前のブログの通り、ユーザーが設定をするべき部分はとても少ないです。

1. [中央アカウント] S3バケットを作成
2. [中央アカウント] SSM Inventoryの「リソースデータの同期」を作成
3. [子アカウント] 対象サーバにSSM Agentをインストール
4. [子アカウント] SSM Inventoryの「リソースデータの同期」を作成

構成（AWSにより自動で作成される部分含む）

中央アカウント側でリソースデータの同期を作成すると、S3に配置されたインベントリ情報をマネジメントコンソールに表示するためにGlue クローラーとGlue データカタログが作成されます。

AWS Glueは様々なデータソースのメタデータを管理・加工するマネージドサービスです。
Glue クローラーが、S3やDynamoDB等のデータソースからデータを刈り取り、Glue データカタログにメタデータを保存します。
保存されたメタデータはAthenaやRedshift、EMRに連携可能です。

SSM Inventoryでは、このGlue クローラーとGlue データカタログが自動で作成されます。
SSM Inventoryにより作成されるGlue クローラー、Glue データカタログは、予め定められた命名規約に基づき作成されます。

Glue クローラ―

Glue クローラーはAWSSystemsManager-{S3バケット名}-{Region}-{AWSアカウントID}という名前で作成されます。

Scheduleを見てみると、12時間毎の00分にクローラーJobが動くことがわかりました。
「S3バケットにインベントリデータがあるのにSSM Inventoryの画面上で表示されない」と思ったら、「最後にGlue クローラーが稼働した時間」を調べると良いです。

下のキャプチャをご覧ください。
Glue クローラーのJobが実行されるたびに、S3内の全てのフォルダーがクロールされることがわかります。
EC2のインベントリ情報が更新されるとS3内のファイルも更新されますが、ファイルが更新されGlue クローラーのJobが実行されたら、Glue データベースのメタデータが更新されるということですね。

いつ稼働したかは「Crawler runs」で確認できます。

もちろん、手動でクローラーを動かすこともできます。

Glue データカタログ（データベース）

Glue データカタログは、Glue内のデータをひとまとめにしたものです。

Glue データカタログ
　┣ Database（データベース）
　┃　┗ Table（テーブル）
　┃　　　┗ Data（データ）
　┗ Database（データベース）
　　　┗ Table（テーブル）
　　　　　┗ Data（データ）

Glue データベースは{S3バケット名}-{Region}-databaseという名前で作成されます。

AWS Systems Managerで「リソースデータの同期」を作成する画面では、
同期名とバケット名だけを指定すればよいので、本来は全く意識する必要がない部分です。

Tablesを見ると、見覚えのある名前のテーブル名が表示されていることがわかります。
SSM Inventoryの画面で表示されるインベントリタイプと同じですね。

S3バケット内のオブジェクト名と一致していることがわかります。

SSM Inventoryのインベントリタイプのプルダウンに表示されるまでの裏の仕組み、理解できましたでしょうか。

続く

SSM Inventoryはそれ単体でマネージドなサービスというわけではなく、複数のマネージドサービスを組み合わせているということがわかりました。

2部では、具体的にどのようなエラー・トラブルに直面したのかを紹介したいと思います。

今回は以上です。