4月ももう下旬に入りましたね(・ω・)
個人的な話ですが、私は先月1歳になった娘を、今月から保育園に預けており、
5月1日に産休・育休から仕事復帰予定です。
今月は保育園に慣れるための期間として、
まずは保育園で親と一緒に1時間過ごすところから始めて、徐々に預ける時間を延ばしています。
なので今は、なぜか出産後で１番自分時間（≒IT勉強時間）を確保できているという奇跡。
が、仕事と育児と家事の両立が始まる来月からは、またアメブロを開きさえしない気が(^-^;
一応生きてはいるはずなので、たまに出現した際はよろしくおねがいします。笑
それにしても、どうにかやりくりされている世の中のワーママの皆さん、本当にすごい。。
ということで、前置きが長くなりましたが、今日もAWSを勉強していきます。
今回のテーマはAWS Cloud Mapです。
（2023年4月時点の情報です）
もくじ
・構造
１．AWS Cloud Mapとは
AWS Cloud Mapとは、様々なリソースに対して任意の名前をつけて管理、名前解決を行うサービスである。
◎Cloud Mapを使うと何が良いのか？
Cloud Mapを使用する最大のメリットは、
登録リソースの場所の更新作業が丸ごと不要になることである。
ここでいうリソースとは、例えば
EC2インスタンス、データベース、キュー、オブジェクトストア、カスタマー定義のマイクロサービスなど、
アプリケーションを構成する様々なサービス全般を指す。
これらリソースが力を合わせて１つのシステム・ITサービスを提供するわけだが、
機能するためには、リソース同士がアクセスできる必要がある。
アクセスのためには、そもそもリソースが、
依存リソースの場所（IPアドレス等の情報）を知らないと話にならない。
一方で、アプリケーションを構成するリソースは、
特にマイクロサービスや大規模システムなどで、複雑で多岐にわたることも多い。
リソースの位置情報について、必要に応じてコードや設定ファイルの中身を手動で書き換え、
テスト・管理するのは非常に大変な作業である。
（1つでも漏れやミスがあるとシステムがうまく機能しなくなる。
しかも環境依存情報なので、テスト時にミスに気づけず最悪の結果になることも(-_-;)）
さらに、トラフィック量によって動的にリソースがスケールアップ／ダウンするような場合であっても、
各時点でのリソースの状態や場所を都度正確に把握し、アクセスできる必要がある。
こういった課題を解消してくれるのが、AWS Cloud Mapである。
AWS Cloud Mapは、リソースを一度登録してしまえば、当該リソースの場所を動的に管理してくれる。
AWS Cloud Mapは、特に動的にリソースの場所が変わっていくようなコンテナ・アプリケーション等で、よく利用されている。
◎DNSとは何が違うのか？
ここで、リソースの場所を示す重要な情報＝IPアドレスが変わったとしても、
DNSを利用して、名前やシノニムで場所を特定できるから、
わざわざCloud mapを利用しなくても良いのではと思う人もいるかもしれない。
実際、Cloud Mapも、一部機能ではDNSの名前解決の仕組みを利用して、
リソースの場所を特定できるようになっている。（３．リソースの検出方法で説明）
Cloud Mapですごいのは、IPアドレスの無いリソースでも、管理対象にできるという点である。
IPアドレスの他、URLやARN（AWSリソースネーム。AWSリソースを一意に識別する名前のこと）によって表せるリソースであれば、全て管理対象にできる。
ARNで表せるリソース全て、なので、実質的にAWSのサービス全てを管理できるということだ。
２．Cloud Mapの構造
AWS Cloud Mapの構造は以下のようになっている。
◎構造
AWS Cloud Mapは以下の３つのオブジェクトで構成される。
| オブジェクト | 説明 |
|---|---|
| 名前空間 | サービスの論理グループ。 名前空間毎の単位で、リソースの検出方法（詳細は３．リソースの検出方法参照）を指定する。 |
| サービス | サービスインスタンスを登録するためのテンプレート。 ヘルスチェック方法や、DNSを利用する場合のルーティング方法などを指定する。 |
| サービスインスタンス | 登録するリソース自体の情報。 |
名前空間（ドメイン）内にサービスを作成し、さらにサービスインスタンスを登録していくような内包関係となる。
Cloud Mapへの登録情報は専用のレジストリに保存される。
◎サービスインスタンスとして登録できるもの
１．AWS Cloud Mapとはでも書いた通り、
Cloud Mapにサービスインスタンスとして登録できるリソースは、基本的にAWSリソースの全てである。
登録するリソースは、以下の３つの中から、タイプをあらかじめ指定する必要がある。
| タイプ | 説明 |
|---|---|
| IPアドレス | サービスインスタンスに関連付けられたリソースが、 IP アドレスを使用してアクセスできる場合に指定する。 ３．リソースの検出方法に記載の、どの検出方法であっても指定できる。 |
| EC2インスタンス | サービスインスタンスに関連付けられたリソースが、 EC2インスタンスを使用してアクセスできる場合に指定する。 検出は、３．リソースの検出方法記載内容のうち、API呼出しのみ可能。 |
| その他のリソース | サービスインスタンスに関連付けられたリソースが、 IPアドレスを持たないかつ、EC2インスタンスでない場合に指定する。 リソースへのアクセス情報を、キー&値で別途設定する必要がある。 ３．リソースの検出方法に記載の、どの検出方法であっても指定できる。 |
３．リソースの検出方法
Cloud Mapに登録済みのリソースを検出する（名前解決してリソースの場所を知る）方法には、以下の２種類がある。
| 検出方法 | 説明 |
|---|---|
| API呼び出し | "DiscoverInstances"というAPIを呼び出すことで、名前解決する方法。 APIのパラメータには、名前空間やサービス名、インスタンス名の他、インスタンスの状態（異常なものを省く等）、 リソース情報に紐づくキー&値ペアなども指定できる。 |
| DNSクエリ | DNS名前空間を自動作成し、DNSクエリを発行して名前解決する方法。 DNS名前空間は、パブリック／プライベートのどちらにするか指定できる。 DNS名前空間を作成すると、同じ名称でAmazon Route 53のホストゾーンが Cloud Map によって自動的に作成される。 |
４．Cloud Mapのヘルスチェック機能
オプションの有料機能だが、Cloud Mapにヘルスチェック機能を持たせることもできる。
ヘルスチェック結果により、正常動作中のリソースだけを抽出して検出する運用が可能となる。
ヘルスチェックの方法は以下2つから選べる。
| 方法 | 説明 |
|---|---|
| Route 53 ヘルスチェック | パブリックのDNSクエリでリソース検出する場合のみ指定可能な方法。 Cloud Mapへのインスタンス登録時、ヘルスチェックがRoute 53に自動で関連づけられる。 インスタンスの状態確認は、Route 53 コンソールまたは Amazon CloudWatchでできる。 |
| カスタムヘルスチェック | Route 53 ヘルスチェックを利用できない場合（プライベートのDNSクエリまたはAPI呼び出しでリソース検出する場合）や、 サードパーティのヘルスチェッカーを利用したい場合などに、 ヘルスチェック方法をカスタマイズすることができる。 ただし、ヘルスチェックを機能させるには、ヘルスチェッカーもインスタンスと同じ VPC にある必要がある。 |
※ヘルスチェック機能はオプションのため、ヘルスチェック無しに設定して、
正常／異常に関わらずサービスインスタンスへルーティングさせることもできる。
今回は以上！