業務でのAWS活用〜LambdaからGCPのサービスを利用/AWS PrivateDNSで名前解決〜

[AWSアドベントカレンダー](https://qiita.com/advent-calendar/2019/aws)の25日目の記事です。
# 概要
自分が今年業務で使ったAWSをその業務シーンと共に自分の振り返りのため(PrivateDNSは同じチームの他のメンバーが構築してくださったため、改めて自分で構築して再確認)に書いていきます(アウトプット駆動学習)。

![スクリーンショット 2019-12-25 22.39.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/8531429f-1433-f0b7-8052-c3c60287b38f.png) ![ダウンロード.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/8d38fb32-76d4-24f7-d361-a80ba7679892.png)


# 1:AWS LambdaからGCPのサービスをリクエストする
## 業務シーン
業務で扱うコンテンツの文脈解析をするためにGCPのAutoML [Natural Language Classification](https://cloud.google.com/natural-language/automl/docs/?hl=ja)を使うことになりました。元データがAWSのRDSにあるので、**AWSのリソースからからGCPのAPIを叩く**ことを考えました。処理がとてもシンプルだったので今回はLambdaでバッチ処理を組む想定をしました。(まだ検証中です)。開発言語としてGolangを利用しています。

![スクリーンショット 2019-12-25 22.34.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/c34d8e33-0cf1-2a4a-fe03-0f0e8d7baafb.png)
https://cloud.google.com/automl/?hl=ja

## 手順
1: [Analyzing Documents](https://cloud.google.com/natural-language/automl/docs/predict)を参考に、AutoMLのPredictのAPIを叩くためのプログラムを準備します(下のは本当にサンプルそのままです。上のリンクのドキュメントを読む際は言語で英語を選択してください。日本語versionは最新のものに追いついてないです。)
![スクリーンショット 2019-12-25 22.06.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/1509e22e-c333-176e-9c80-707b09682be3.png)

2: [Getting Started with Authentication](https://cloud.google.com/docs/authentication/getting-started?hl=ja)を参考に、GCPのアカウントでサービスアカウントキーを発行します。
GCPの認証については詳しくは[こちら](https://cloud.google.com/docs/authentication/?hl=ja)をご覧ください。

3:Lambda関数を作成し、コードとサービスアカウントキーをアップロード

AWSでコンソールなどを使ってLambda関数を作成します。その後、
1で作成したプログラムをbuildしたものと、2で作成したサービスアカウントキーのJSONファイルをzipファイルでまとめて※、Lambda関数にアップロードします。業務ではLambda関数の作成でAWSの[Sam](https://aws.amazon.com/jp/serverless/sam/)を利用しています。

※サービスアカウントキーの置き場が正しくないと思うので、いい案がありましたらご教示ください :bow:

ここで、環境変数としてをキー名として、値に2で作成した`サービスアカウントキーのJSONファイル`名を指定します。

> 環境変数を設定すると、Google Cloud Client Library を使用するときに、コード内に認証情報を明示的に指定する必要はありません。クライアント ライブラリによって、認証情報を暗黙的に判別できます。

https://cloud.google.com/docs/authentication/getting-started

![スクリーンショット 2019-12-25 22.23.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/b016dead-2536-1afe-ae42-70a0dc87f890.png)


4:Lambda関数の実行
![スクリーンショット 2019-12-25 19.06.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/64b59ebd-af5a-4c50-3872-32ab3850343a.png)
上のように、モデルで定義したラベルごとにスコアが返ってきます。(上のスクショではラベル名は伏せています)
(スクショがローカルでの実行結果のものになってました、後でLambdaでの実行結果のものに置き換えておきます)

### GCPの認証

なお、今回はAutoMLを例としましたが他のGCPのAPIも基本的に、外部のオンプレサーバーやパブリッククラウドからGCPのサービスにリクエストする際の認証方法としてサービスアカウントキーの利用を推奨されています。

![スクリーンショット 2019-12-25 22.42.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/85451dc4-c093-f42a-e950-03c2c5316dd8.png)
https://cloud.google.com/docs/authentication/?hl=ja

# 2：PrivateDNS
## 業務シーン
業務で開発していたAPIで内製の別チームが開発したAPIを利用するケースがありました。そのAPIは**各開発環境ごと(DEV/STG/PRD)エンドポイントが提供されておらず、HostによってAPI利用側が切り替える必要**がありました。

## 手順
(例として適当にqiitaのドメインを名前解決するケースで書きます)
AWSの[Fargate](https://aws.amazon.com/jp/fargate/)を使ってAPIを開発していたのですが、[こちらの資料](https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/AWS_Fargate.html)にある通り、Fargate型のECSのタスク定義にはextraHostsが利用できませんでした。
そこで、AWSの担当の方にお聞きしたところ、**１：Route53プライベートホストゾーンでの振り分けの実施**、**内部DNSを作る**の二択で、前者の方が楽なので実際に1の方法で名前解決することにしました。

１： ホストゾーンを作成
![スクリーンショット 2019-12-25 21.13.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/d12be154-8927-c8d5-1370-ac465d4fee42.png)

２：レコードを作成
![スクリーンショット 2019-12-25 21.14.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/8e1ca6d5-0724-df38-e25b-9b498a20afe2.png)
これにより、`www.qiita.com`に対して今回したAレコードのIPで`192.0.2.235`名前解決できるようになります。

３:DHCPオプションの新しいセットを作成
[VPCでのDNSの使用](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-dns.html)にあるように、独自のDNSサーバーを使用する場合はVPC用のDHCPオプションの新しいセットを作成します。

### DHCPオプションセットとは
DHCP:TCP/IPネットワークのホストに設定情報を渡すための規格です。これにより、VPCとDNSを紐付けることができ、VPC内のインスタンスやコンテナがドメインを2で指定したIPアドレスで名前解決することができるようになります。

![スクリーンショット 2019-12-25 21.39.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/63ab6362-523d-18ab-bd6b-d2d76b542071.png)

参考
[DHCP オプションセット](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_DHCP_Options.html)
[DHCP オプションセットの作成](https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/dhcp_options_set.html)

４： VPCのDHCPオプションセットを変更
![スクリーンショット 2019-12-25 21.50.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/8d67d868-9fa2-e8e1-3168-4446afb2db52.png)

![スクリーンショット 2019-12-25 21.53.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/87503607-10e9-e26c-6f0e-cdce71752a27.png)

以上の作業でPrivate DNSの設定は完了です。
nslookupコマンドなどで正しく名前解決されていることを確認します。

# まとめ
半分くらいGCPの内容も入ってしまいましたが、今年業務で扱ったAWSのサービスについて振り返ってみました。Fargateを使うことで今回書いたようにextra hostsが利用できないという不便さはありますが、それ以外はサーバーの管理が不要でBlue/Greeデプロイやオートスケールに対応していてとても使い勝手がいいと感じています。また先日のreIneventで発表されたALBの重み付けルーティングと組み合わせてカナリアリリースもできるのでとても便利だと感じています。今後も引き続き業務でAWSを上手く利用していきたいと思います、ありがとうございました。

![christmas_santa_sori.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/274080/8c69a7a5-836d-6d8d-3fef-d57887170f07.png)
https://www.irasutoya.com/2012/10/blog-post_24.html