目次
はじめに
テレワークの巣ごもり生活で久しぶりに筋トレしたら意外に楽しくなってハイになってやってたら次の日に猛烈に筋肉痛に襲われたSRE課の甫立です。
AWSのRoute53のドキュメントを確認していてユースケースの一つとしてCloud Mapとの連携した使い方が紹介されていたので、今日は色々調べてみました。
Cloud Mapはあまり聞かないサービスかもしれませんが、複数のWEBサイトを扱う上では便利に使えるサービスです。
AWS Cloud Mapとは?
以下は公式の引用です。
AWS Cloud Map は、アプリケーションで使用されるバックエンドサービスやリソースのマップを作成および維持することができる完全マネージド型のサービスです。AWS Cloud Map の仕組みを以下に示します。
リソースの検索に使用する名前を識別し、リソースの検索方法を指定する名前空間を作成します。これを行うには、AWS Cloud Map の DiscoverInstances API コール、VPC の DNS クエリ、またはパブリック DNS クエリを使用します。1 つの名前空間には通常、1 つのアプリケーション (例: 請求アプリケーション) 用のサービスがすべて含まれています。
AWS Cloud Map サービスは、AWS Cloud Map を使用してエンドポイントを検索するためのリソースのタイプごとに作成します。たとえば、ウェブサーバーおよびデータベースサーバーのサービスを作成します。
サービスは、アプリケーションで別のリソース (例: 別のウェブサーバー) が作成される際に、AWS Cloud Map で使用されるテンプレートです。名前空間を作成したときに DNS を使用してリソースを検索することを選択した場合、サービスにはウェブサーバーの検索に使用するレコードの種類に関する情報が含まれています。また、サービスは、リソースの状態をチェックするかどうか、またチェックする場合は Amazon Route 53 ヘルスチェックを使用するか、サードパーティー製のヘルスチェッカーを使用するかを示します。
アプリケーションでリソースが追加されると、AWS Cloud Map の RegisterInstance API アクションが呼び出される場合があります。この場合、サービスインスタンスが作成されます。サービスインスタンスには、アプリケーションでリソースを検索する方法に関する情報が含まれます。この際、DNS、または AWS Cloud Map の DiscoverInstances API アクションを使用するかどうかは関係ありません。
リソースに接続する必要がある場合、アプリケーションは DiscoverInstances を呼び出し、そのリソースに関連付けられている名前空間およびサービスを指定します。その後、AWS Cloud Map によって、1 つ以上のリソースの検索方法に関する情報が返ります。サービスの作成時にヘルスチェックを指定した場合は、AWS Cloud Map よりヘルスインスタンスのみが返ります。
AWS Cloud MapはEC2やS3といったリソースを検索しやすいように名前空間という形でサービスに紐づいた名前と情報を統合的に管理するリソースの検索窓のような役割を提供しています。
もう少し具体的に言うと、システムを組む場合にはリソース間でIPアドレスの参照を行う必要がありますが、AWS Cloud Mapで名前とIPの紐づけを登録することでリソースの場所をマップのように管理でき、参照元を統合することが可能になります。
以下のような順位でリソースを管理します。
- [名前空間]
- [サービス]
- [サービスインスタンス]
ドメインでいうコモンネームのようなものです。
ドメインでいうとサブドメインのようなものです。
サービスと紐づけるリソースのIPアドレスなどの情報登録します。
ユースケース
-
マイクロサービス
マイクロサービスは通常コンテナを使って素早くリソースの起動と終了をするので手動で情報を更新するのは時間がかかります。AWS Cloud Mapはコンテナサービスと密接に連携が可能であり、動的に場所を検出するため、クラウドネイティブにリソース間の連携をすることができます。 -
継続的な統合とデプロイ
複数の場所、リージョンにアプリケーションをデプロイすべてのリソースで行う必要があります。AWS Cloud Mapは統合的にリソースに紐づく情報を管理するので、対象の検出が容易になります。
軽くハンズオン
解説だけで終わってしまうのもわかりにくいのでここからは実際に触ってみます。
このハンズオンの想定としてはVPCとそのVPC内のpublic subnet内に紐づいているEC2がすでに作成されている想定です。
使用するVPCのIDは後ほど使用するので控えておいてください。
また、コンソール上でCloudMapを扱いますが、APIコールによるサービス検出の検出を確認するためにAWS CLI(コマンドラインインターフェース)も最後に少し扱います。
名前空間の作成
下記のURLからAWS Cloud Mapのコンソールにアクセスします。
「名前空間の作成」をクリックして下記の様な画面になります。
- 名前空間名
- 名前空間の説明
- インスタンスの構成
任意で名前を入力する。
下の「インスタンスの構成」でDNSクエリでの検出を有効にする場合は、ここで入力した名前がRoute53のホストゾーンとして登録される点には注意です。
DNSでのrootドメインのようなものなのでサーバのホスト名となる名前を入力する必要があります。
後で用途を識別しやすいように、名前空間の説明を入力しましょう。
ここでは「sample.com」とします。
ここで選択した項目で今後どのように検出できるようにするかが異なります。
下記では軽く特徴を説明します。
1. API呼び出し
AWS CLIやプログラムからのAPIコールで呼び出すことができます。
コンソールにアクセスせずにコマンドライン上でリソース情報を参照ができるようになります。
2. API呼び出しとDNSクエリ
iの検出方法に加えてDNSクエリによる検出が可能となります。
登録すると、Route53のホストゾーンがPrivate Hosted Zoneとして自動的に作成されます。
こちらは検索を可能とするVPCの指定が必須となります。
プライベートホストゾーンなので登録する際に対象となるVPC IDの登録が必須です。
DNSクエリがVPC内に登録しているリソースのみで完結する場合に
選択します。
3. API呼び出しと公開DNSクエリ
iの検出方法に加えて公開で外部からでもDNSクエリで検出が可能となります。
登録すると、Route53のホストゾーンがPublic Hosted Zoneとして
自動的に作成されます。
今回はiiのAPI呼び出しとDNSクエリを使用します。
また、VPCは事前に作っているものを使用します。指定はプルダウンで自分のVPCIDを選択しましょう。
記入内容に間違いがなければ「名前空間の作成」をクリックします。
クリック後は登録されるまでにしばらくかかるので待ちましょう。
完了すると名前空間のリストに正常に名前空間が表示されます。
Route53で確認
名前空間を登録した後にRoute53のコンソール画面で「ホストゾーン」を確認すると
以下の様に登録されているのが確認できます。
作成者がCloud Mapになっており、説明にもNamespace IDが記述
されているので識別しやすくなってます。
ここで一点注意ですが、Route53のコンソール上ではCloud Mapで作成したホストゾーンは削除ができません。削除を実施したい場合はCloud Mapのコンソールにアクセスし、名前空間から削除するとホストゾーンも消えます。
○サービスの登録
AWS Cloud Mapのコンソールに戻って「名前空間」から自分の作成した名前空間を
クリックすると名前空間の情報が確認できます。
そこから「サービスの作成」をクリックします。
以下の様に表示されるので必要情報を記入しましょう。
-
サービス名
判別しやすい名前で登録しましょう。
サービスはリソースのグループ名のようなもので、サブドメインと同じように
登録します。 -
サービスの説明
説明は任意でつけます。 -
ルーティングポリシー
ここで設定できるのは「加重ルーティング」と「複数値回答ルーティング」のみです。加重ルーティングポリシー
指定した比率で複数のリソースにトラフィックをルーティングする場合に使用します。複数値回答ルーティングポリシー
ランダムに選ばれた最大 8 つの正常なレコードを使用して Route 53 が DNS クエリに応答する場合に使用します。
今回は加重ルーティングポリシーとします。
-
レコードタイプ
ここで設定できるのは「Aレコード」、「AAAAレコード」、「SRVレコード」、「CNAMEレコード」です。Aレコード
ドメイン名のDNSクエリに対してIPv4アドレスを応答するためのレコードです。AAAAレコード
ドメイン名のDNSクエリに対してIPv6アドレスを応答するためのレコードです。SRVレコード
負荷分散のためのレコードで、「Priority」、「Weight」、「Port」、「ドメイン名」を登録します。
Priorityは正常時にルーティングされる「優先度」のことで値が低いほど、優先度が高くなります。
WeightはPriorityが同じ値の場合にどれだけ優先されるかの「重み」のことで、値が高いほど優先されます。
CNAMEレコードもありますが、加重ルーティングの場合には使用できません。
ここはAレコードを選択します。
-
TTL
キャッシュを保持する秒数を指定します。ここはデフォルトの300のままにします。 -
ヘルスチェックのオプション
ヘルスチェックは登録したリソースが正常化どうかを指定するものです。
外部のヘルスチェックツールを利用する場合などはカスタムヘルスチェックを選択します。
今回は利用しないのでヘルスチェックなしで選択します。
今回は名前空間の作成のインスタンス構成で「API呼び出しとDNSクエリ」を指定したため、
「Route 53」によるヘルスチェックは選択できません。
記入内容に間違いがなければ「サービスの作成」をクリックします。
すると名前空間情報のサービスリストに作成したサービスが登録されます。
サービスインスタンスの登録
サービスインスタンスはサーバ内のサービスの単位ですね。
自分の作成した名前空間の名前をクリックし、さらにサービスの名前をクリックすると下の方に「サービスインスタンスの作成」とあるのでクリックしましょう。「サービスインスタンスの登録」の画面になるのでいかの情報を入力します。
-
サービスインスタンスID
APIで呼び出しを行う際に使用するIDをここで指定します。 -
IPv4アドレス
サービスに紐づいているIPアドレスを指定します。
今回は事前に用意していたEC2インスタンスのプライベートIPを指定しました。 -
ポート
サービスにデフォルト以外のポートを指定している場合などは設定できます。 -
カスタム属性
サービスインスタンスにタグがつけれます。
後から検索をかける場合にさらに検索がしやすくなるので設定しましょう。
入力した情報に間違いがないかを確認したら「サービスインスタンスの登録」をクリックします。
再びRoute 53で確認
再びRoute 53のコンソール画面でCloud Mapで作成したホストゾーンを確認すると先ほど作成したサービスインスタンスの情報が新しくAレコードとして登録されているのが確認できます。
使ってみる
最後に実際はどのように検索して参照できるかをコマンドライン上で確認します。
-
CloudMapでの検出
コマンドとその結果は以下の様になります。aws servicediscovery get-namespace --id ns-uwtvewi3vh7pc6jc { "Namespace": { "Id": "ns-uwtvewi3vh7pc6jc", "Arn": "arn:aws:servicediscovery:ap-northeast-1:010045182340:namespace/ns-uwtvewi3vh7pc6jc", "Name": "sample.com", "Type": "DNS_PRIVATE", "Description": "ブログ用名前空間", "Properties": { "DnsProperties": { "HostedZoneId": "Z0711874R02U82ELYOBJ" }, "HttpProperties": { "HttpName": "sample.com" } }, "CreateDate": "2021-01-30T05:21:47.062000+09:00", "CreatorRequestId": "7c9e2908-bd22-4263-9e56-253c794244d4" } }
HostedZoneIdの値は後ほど使うので控えましょう。
次にサービスインスタンスの情報を読み取ります。aws servicediscovery list-instances --service-id srv-wrsmgybr37sxunmu { "Instances": [ { "Id": "EC2", "Attributes": { "AWS_INSTANCE_IPV4": "10.1.1.70", "Name": "blog-sample" } } ] }
-
Route 53による検出
次にDNSでどのように登録されているかを確認します。
コマンドは以下の通りです。aws route53 list-resource-record-sets --hosted-zone-id Z0711874R02U82ELYOBJ { "ResourceRecordSets": [ { "Name": "sample.com.", "Type": "NS", "TTL": 172800, "ResourceRecords": [ { "Value": "ns-1536.awsdns-00.co.uk." }, { "Value": "ns-0.awsdns-00.com." }, { "Value": "ns-1024.awsdns-00.org." }, { "Value": "ns-512.awsdns-00.net." } ] }, { "Name": "sample.com.", "Type": "SOA", "TTL": 15, "ResourceRecords": [ { "Value": "ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400" } ] }, { "Name": "service.sample.com.", "Type": "A", "SetIdentifier": "EC2", "Weight": 1, "TTL": 300, "ResourceRecords": [ { "Value": "10.1.1.70" } ], "HealthCheckId": "479de586-7a4e-47e6-b29a-5ad52e26e1c6" } ] }
設定したプライベートIPがレスポンスとして出力されました。
リソースのクリーンアップ
使い終わったらコンソールから今回作成したリソースを削除していきましょう。
AWS Cloud Mapのコンソールにアクセスします。
名前空間から削除しようとしてもサービスとサービスインスタンスがあるとエラーとなりますので、サービスインスタンスから消していきましょう。
「名前空間名」→「サービス名」の順でクリックしていきます。
「サービスインスタンス」のリストから今回追加した「サービスインスタンス名」にチェックを入れて「登録の解除」をクリックします。
次に上にスクロールすると「サービス:[サービス名]」の横の「削除」をクリックし、
サービスを削除します。
それが完了したら名前空間名をクリックし、「削除」をクリックします。
完了したら名前空間作成と同時にできたホストゾーンも消えているはずなのでRoute 53のコンソールを確認してみましょう。
これで簡単なハンズオンは完了です。
最後に
今回はAWS Cloud Mapの概要と基本的な使い方について説明しました。
今回の簡単なハンズオンの内容はあまり使われない方法でしょう。
ユースケースとして多く使われているのはECSやEKSといったコンテナサービスと連携して自動で名前とIPアドレスを登録する方法ですので、それに関してはまた別の記事として作成させていただきます。
最後まで読んでいただきありがとうございました。
しばらくバリバリの新人、甫立です。
クラウドベリージャム:プロフィールページ