AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

12

作者別: Kitano Yuichi

re:Invent 2018 新機能!LambdaのCustom Runtimesを試してみた

Pocket

Hello, サービス開発チームの北野です。

re:Inventでラスベガスに来ています。とうとう最終日です。

今日はKeynoteでServerless関連が大きくアップデートしました。
LambdaのRubyサポート, Lambda Layers, API GatewayのWebSocket対応, ALB for Lambdaなどなど、
どれも使ってみるのが楽しみになるアップデートでした。

LambdaのCustom Runtimesの発表を見て、
「これはもしやハンズラボの謎技術ユニケージ on Lambdaができるのでは…?」
という悪魔のささやきが聞こえましたが、無視しました。

ちなみに私は業務でユニケージを触ったことはございません。

それはともかく、LambdaのCustom Runtimesが気になったので、公式チュートリアルに沿って試してみました。

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-walkthrough.html

Lambdaの作成

まずはLambdaをマネジメントコンソールから作成します。
ランタイムに「独自のランタイムを使用する」という選択肢が増えているので、これを選びます。
名前とロールは適当に設定して関数を作成します。

独自のランタイムを使用する場合、プログラムはマネジメントコンソールで編集できないようなので、プログラムはローカルマシンで作成します。

bootstrapの作成

独自のランタイムを使用する場合、bootstrapシェルスクリプトを起点にLambdaが動くようです。
サンプルスクリプトを見ると、LambdaのRuntimeAPIに対してGETでHTTPアクセスしてLambdaを起動したEventを取得して、
LambdaのRuntimeAPIに対してPOSTでHTTPアクセスしてResponseを返す仕組みになっています。

今回はサンプルスクリプトをちょっとだけ変更して使います。

bootstrap

function.shの作成

bootstrapから呼び出して実行するシェルスクリプトfunction.shを作成します。
シェルスクリプトのfunctionには戻り値が無いので、標準出力を使って擬似的に戻り値があるような振る舞いをさせます。
シェルスクリプトに馴染みがないとよくわからないと思うので、bootstrapの振る舞いと合わせて後ほど解説します。

function.shもサンプルスクリプトを少し変更して使います。

function.sh

bootstrapとfunction.shの振る舞い

シェルスクリプトの動作について少しだけ解説します。
まず環境変数$_HANDLERには、Lambdaで設定しているハンドラが設定されます。
今回はfunction.handlerという値が設定される想定です。

そしてbootstrapの6行目
source $LAMBDA_TASK_ROOT/”$(echo $_HANDLER | cut -d. -f1).sh”

echo $_HANDLER | cut -d. -f1
で、function.handlerを”.”で文字列分割した1つ目を取得しています。
これを展開すると、
source $LAMBDA_TASK_ROOT/function.sh
ということになります。

17行目も似たような形で、
RESPONSE=$($(echo “$_HANDLER” | cut -d. -f2) “$EVENT_DATA”)

echo “$_HANDLER” | cut -d. -f2
で、function.handlerを”.”で文字列分割した2つ目を取得しています。
これを展開すると、
RESPONSE=$(handler “$EVENT_DATA”)
ということになります。
このhandlerはfunction.shで定義したfunctionで、handler実行時の標準出力がRESPONSE変数に格納されます。
$()を使ってfunctionの標準出力を変数に格納することで、擬似的に戻り値があるような振る舞いをさせています。

Lambdaのコードアップロード

作成した二つのファイルはzip圧縮して一つのファイルにします。

  • bootstrap
  • function.sh

マネジメントコンソールを開いて、コードエントリタイプで「.zipファイルをアップロード」を選択します。
アップロードボタンを押して作成したzipファイルを選択し、ハンドラを修正して保存ボタンを押します。

これで動かす準備が出来ました。テスト実行してみましょう。

Lambdaのテスト実行

右上の方にあるテストボタンを押します。

テスト用のEventを作る必要があるので、名前だけつけて適当に作成します。

作成したEventが設定されていることを確認して、再度テストボタンを押します。

「実行結果:成功」でちゃんと動いています。やったね!

終わりに

LambdaのCustom Runtimesを動かすことができました。
便利だなと思う半面、せっかくのシンプルなLambdaにだいぶ管理しなければならないことが増えてしまう印象があり、Custom Runtimesの使用は慎重に検討したいところです。
選択肢が増えたことはとても良いことだと思うので、本当にCustom Runtimesを使う必要があるのか?他にもっと良い方法が無いか?と自問自答して、適切な技術選択をしていけたらと思います。

Pocket

re:Invent 2018 Cloud9でAWS CLI v2 を動かそう

Pocket

Hello, サービス開発チームの北野です。

現在、re:Inventでラスベガスに来ています。勝手にブログ強化週間中です。

ハンズラボCLI大好き代表としては聞き逃がせないなと思って、
DEV322-R – [REPEAT] What’s New with the AWS CLIのセッションを聞いてきました。

以前からv2の話は少しずつでていましたが、ついにv2のdeveloper releaseが出たようです。
https://github.com/aws/aws-cli/releases/tag/2.0.0dev0

現在のCLIと互換性が保証されないものの、補完機能が強力になって、wizard機能がつき、yaml出力に対応するので、とっつきやすくなるんじゃないかと期待しています。

Cloud9とAWS CLI

実はCloud9とAWS CLIの相性がすごく良いと思っていて、私はIDEとしてよりブラウザで動かせるシェル環境としてCloud9を愛用しております。

Cloud9でAWS CLIを動かすときは、AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYを意識する必要がなくなります。
Cloud9がうまいことやってくれて、ログインしたユーザーが操作できる範囲の権限を持った一時的なCredentialsを生成してくれるのです。

どうなっているのかというと、Cloud9のここの設定をONにしておくと(デフォルトON)、

Cloud9が~/.aws/credentialsに一時的なCredentialsを生成して設定してくれます。便利。

Cloud9にAWS CLI v2をインストール

まずは最初にCloud9にインストールされているawscliをアンインストールしちゃいます。

AWS Developer Blogを参考に、GitHubリポジトリをソースにしてpip installします。

https://aws.amazon.com/jp/blogs/developer/aws-cli-v2-development/

最後に、ダウンロードされたソースの中身をec2-userがさわれるようにchownします。

awsコマンドのバージョンを確認して、2.0.0dev0になっていたら無事インストールできました。

AWS CLI v2を使ってみる

DynamoDBのテーブル名まで補完してくれるらしいので、DynamoDBを作って確かめてみます。
適当な名前のDynamoDBのテーブルを作ります。

補完を適用するためのコマンドを実行して、テーブル名が補完できそうな
aws dynamodb describe-table --table-nameまで入力します。

ここで<TAB>キーを押すと…先程作ったDynamoDBのテーブル名が補完されました。すごい!

終わりに

互換性が保証されていないという点には注意が必要そうですが、補完が強力になってCLIが使いやすくなりそうです。
v2正式リリースまで情報を追っていこうと思います。

Pocket

re:Invent 2018 新機能!TransitGatewayを試してみた

Pocket

Hello, サービス開発チームの北野です。

ラスベガスでAWSのイベント、re:Inventに絶賛参加中です。

Monday Night Liveでいろいろ新機能が発表されました!
その中で、「今すぐにでも使いたい!」と私が感じた機能、TransitGatewayを試してみました。
弊社ではそれなりの数のVPCがVPC peeringで相互接続されているので期待大です!

TransitGatewayについてはAWSの公式ブログも公開されています。
https://aws.amazon.com/jp/blogs/news/new-aws-transit-gateway/

これまでのVPC間の接続

これまでVPC間の接続はVPC peeringで行われていました。図にするとこんな感じです。

VPC peeringではVPC1からVPC2を経由してVPC3へ接続するみたいなことはできないので、全てのVPCをVPC peeringする必要がありました。
これが3個程度のVPCなら特に問題はありません。もう少し増やしてみます。

VPCが5個になっただけでVPC peeringの数は10個になりました。
計算するとVPC n個に対して、VPC peeringの数はn*(n-1)/2個必要です。
要するにO(n^2)でVPC peeringの数が増えてしまっていくのです。

これからのVPC間の接続

そこで出てきたのがTransitGatewayです。これを使うと下図のようにVPC間の接続を一つにまとめてくれます。

DirectConnectの接続もサポート予定とのことで、AWSのネットワーク構成がシンプルにできそうです!

TransitGatewayを試してみた

先程の図のように、VPCを3つ作ってその中の一つにCloud9を立てて、残り二つにそれぞれEC2インスタンスを立てます。
VPC1(10.101.0.0/16), VPC2(10.102.0.0/16), VPC3(10.103.0.0/16)の3つのVPCができている状況です。
サブネット、セキュリティグループなどは適切に設定してやります。

まだVPC間はつながっていないので、VPC1にあるCloud9からVPC2にあるインスタンスにpingしても繋がらない状況です。

ここからVPCの画面でTransitGatewayを作成します。

今回はクロスアカウントは試さないので、デフォルトのままチェックを入れず、名前だけ設定してCreateします。

次にTransitGatewayにVPCをアタッチします。

適当に名前をつけて、VPC1のVPC IDとSubnetを選択してCreateします。

同様にVPC2, VPC3もアタッチして、Stateがavailableになるまで少々待ちます。

availableになったあと、TransitGatewayのRoute Tableを確認すると、各VPC(10.101.0.0/16, 10.102.0.0/16, 10.103.0.0/16)にルーティングされていることがわかります。

最後に各VPCのルートテーブルを設定します。

少々おおざっぱですが、10.0.0.0/8の接続を全てTransitGatewayに流してやるように設定します。これを3つのVPCのルートテーブル全てに対して行います。

疎通確認

VPC1(10.101.0.0/16)に立てたCloud9から、VPC2(10.102.0.0/16), VPC3(10.103.0.0/16)に対してpingを行い、通信できていることが確認できました!

終わりに

今回は一つのアカウント内でTransitGatewayを使用しましたが、クロスアカウントで使用することもできます。
将来的にはDirectConnectにも対応するとのことなので、ネットワーク構成をシンプルにできそうで楽しみです!
今後も試していきたいです。

Pocket

re:Invent 2018 認定者ラウンジのススメ

Pocket

Hello, サービス開発チームの北野です。

AWSのre:Invent 2018に参加するためにラスベガスに来ています。
midnight madnessで新サービス、RoboMakerが発表されて他にどんなサービスが発表されるのかとても楽しみです!

今回はAWS認定を取得したくなる、認定者ラウンジのご紹介をいたします。

認定者ラウンジ(AWS Certification Lounge)とは?

AWSのイベント中利用できる、AWS認定取得者のみ入場できるラウンジです。
ソファやデスクが設置され、電源もあるのでゆったりとブログを書いたりすることができます。
(このブログも認定者ラウンジで書いてます!)
入場特典としてトップ写真のようなグッズも貰えました!

今年のre:InventではVenetianとAriaに設置されるみたいです。

ラボのメンバーはVenetianに宿泊しているので、Venetianを利用しました。

コーラを浴びるように飲んだり…

コーヒーブレイクしたり…

時間帯によっては食べ物も提供されているみたいです。

AWS認定を取得することでre:Inventをより快適に過ごすことができるようになります。

AWSではアソシエイト、プロフェッショナル、スペシャリストと様々なレベルの認定があるので、
まずはアソシエイトレベルから目指してみてはいかがでしょうか?

Pocket

AWS Single Sign-On環境の構築を検討してみる

Pocket

こんにちは。クラウドチームの北野です。

現在、AWSアカウントの管理やらAWSインフラのお世話をしたりしています。

ハンズラボではシステムインフラにAmazon Web Service(AWS)を積極的に採用していて、
サーバはほぼ全てAWS上で稼働しています。

何百台というサーバが常時稼働しているので、当然一つのAWSアカウントに収まるわけも無く、何十個ものAWSアカウントが存在しています。

ここまでAWSアカウントが増えてくると、AWSアカウントの管理自体が煩雑になってきます。

AWSヘビーユーザーだと似たような悩みを抱えることが多いと思いますが、
そんな時に参照するのが、AWS公式が公開しているAWS Answersです。

AWSにおけるアプリケーションの設計、構築のベストプラクティスが公開されています。

AWS Answersでは、マルチアカウント戦略のベストプラクティスであるAWS Landing Zoneが公開されています。

今回はマルチアカウント戦略のベストプラクティスの一部分である、AWSログインを一元化するAWS SSO環境の構築を検討してみます。

構成

構成図はこんな感じです。
AWS SSOがバージニア(us-east-1)にしか対応していなので、全てバージニアリージョンで構築しています。

AWS SSOではユーザー管理にActiveDirectoryを使用します。

AWSのDirectoryServiceで連携する必要があるため、マネージドサービスであるMicrosoftADを利用するか、既存のADサーバに対してAD Connectorを利用して連携します。
今回はAD Connector + SimpleADで構築しました。

認証はユーザーID/パスワードで行いますが、多要素認証も無いとセキュリティ的に不安です。
AWS SSOでは自前でRemote Authentication Dial In User Service(RADIUS)サーバを用意することで、多要素認証に対応できます。
今回はEC2インスタンスを建てFreeRADIUSを使って、RADIUSサーバを構築して多要素認証を実現しました。

今後の課題

多要素認証のためにRADIUSサーバを自前で構築してみましたが、本番導入するには運用が辛そうです。

EC2単体で立ててしまうとRADIUSサーバが単一障害点になってしまうため、冗長構成にしなければいけません。
そのために、ADサーバとのユーザ同期、多要素認証用のユーザ情報の分離…と考えだすと大変なので外部サービスを利用したいです。

先人の知恵をお借りすると、DuoやOneLoginといった外部サービスを利用して多要素認証を実現しているようなので、このあたりの利用を検討しています。

AWSには是非AWS SSOの東京リージョン対応とマネージドサービスでの多要素認証に対応していただけたらなーとお祈りしています🙏

Pocket

12