LoginSignup
2
3

More than 3 years have passed since last update.

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

Last updated at Posted at 2019-12-25

AWSアドベントカレンダーの25日目の記事です。

概要

自分が今年業務で使ったAWSをその業務シーンと共に自分の振り返りのため(PrivateDNSは同じチームの他のメンバーが構築してくださったため、改めて自分で構築して再確認)に書いていきます(アウトプット駆動学習)。

スクリーンショット 2019-12-25 22.39.31.png ダウンロード.png

1:AWS LambdaからGCPのサービスをリクエストする

業務シーン

業務で扱うコンテンツの文脈解析をするためにGCPのAutoML Natural Language Classificationを使うことになりました。元データがAWSのRDSにあるので、AWSのリソースからからGCPのAPIを叩くことを考えました。処理がとてもシンプルだったので今回はLambdaでバッチ処理を組む想定をしました。(まだ検証中です)。開発言語としてGolangを利用しています。

スクリーンショット 2019-12-25 22.34.39.png
https://cloud.google.com/automl/?hl=ja

手順

1: Analyzing Documentsを参考に、AutoMLのPredictのAPIを叩くためのプログラムを準備します(下のは本当にサンプルそのままです。上のリンクのドキュメントを読む際は言語で英語を選択してください。日本語versionは最新のものに追いついてないです。)
スクリーンショット 2019-12-25 22.06.21.png

2: Getting Started with Authenticationを参考に、GCPのアカウントでサービスアカウントキーを発行します。
GCPの認証については詳しくはこちらをご覧ください。

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

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

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

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

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

スクリーンショット 2019-12-25 22.23.25.png

4:Lambda関数の実行
スクリーンショット 2019-12-25 19.06.43.png
上のように、モデルで定義したラベルごとにスコアが返ってきます。(上のスクショではラベル名は伏せています)
(スクショがローカルでの実行結果のものになってました、後でLambdaでの実行結果のものに置き換えておきます)

GCPの認証

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

スクリーンショット 2019-12-25 22.42.25.png
https://cloud.google.com/docs/authentication/?hl=ja

2:PrivateDNS

業務シーン

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

手順

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

1: ホストゾーンを作成
スクリーンショット 2019-12-25 21.13.52.png

2:レコードを作成
スクリーンショット 2019-12-25 21.14.26.png
これにより、www.qiita.comに対して今回したAレコードのIPで192.0.2.235名前解決できるようになります。

3:DHCPオプションの新しいセットを作成
VPCでのDNSの使用にあるように、独自のDNSサーバーを使用する場合はVPC用のDHCPオプションの新しいセットを作成します。

DHCPオプションセットとは

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

スクリーンショット 2019-12-25 21.39.32.png

参考
DHCP オプションセット
DHCP オプションセットの作成

4: VPCのDHCPオプションセットを変更
スクリーンショット 2019-12-25 21.50.37.png

スクリーンショット 2019-12-25 21.53.40.png

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

まとめ

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

christmas_santa_sori.png
https://www.irasutoya.com/2012/10/blog-post_24.html

2
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
3