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

HANDS LAB

HANDS LAB ENGINEERS BLOG

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

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

re:Invent 2018 参加レポート Tatonka Challenge

Pocket

ハローエブリワン、サービス開発チームの人見です。

re:Invent 2018でラスベガスに来ています。
昨日アメリカに到着し、20:00頃にホテルにチェックインしたあと、
大急ぎでレジストレーションを済ましてそのままTatonka Challengeに参加して来ました。

Tatonka Challengeというのはre:Invent伝統のチキン大食い対決です。
ルールはざっくりこんな感じです。
・お皿1枚にチキンが12本ある
・1皿食べ終わったらギネス審査員にチェックしてもらってOKがでたら新しいお皿が来る
・1度に1本ずつ食べること 両手でチキン2本もつのはNG
・骨以外は全部綺麗に食べてね
・水でソースを落とさないこと

当日スマホの電池がきれてしまって、
肝心のチキンの写真が撮れなかったのですが、
チキンの大きさは、ケンタッキーよりは小さくて、日本の居酒屋によくある手羽よりは大きいです。

イベント自体は21時開始だったのですが、20時半前ぐらいから並んでいたので
割とすんなり会場入れました。
説明会場で1時間ほど説明を聞いて過ごしたあと、本番会場に移動しました。

本番会場に行く前に、マーチングバンドが演奏してくれてテンションが上がりました。
屈強な大食い達とともに戦士の様な気持ちで本番会場へイン。

自分の番号が書いてある机に座ると、目の前にはビールと水がありました。
チキンとビール、、、最高やん、、、と思いましたが、大食いのプロとして水をチョイス。
ベストプラクティスは水。
周りを見回すとコーラを持参している人がいたので、飲み物は自由みたいです。

MCのファンキーなお姉さんが
「私の口座番号は〜XXXXです!!」という感じの
池崎ちっくなギャグで会場を盛り上げたあと、
いよいよ待ちに待ったチャレンジがスタートしました。

スタートの合図とともに、最初のチキンにかぶりつきました。
滑り出しは好調。
2本目、3本目と順調に食べていき、
5本目あたりからゾーンに入って、
無意識にひたすらチキンを食べ続けました。
異変を感じたのは10本目。
手が重い。。。
甘辛ってなんなの。。。大食いに向いてないやん。。。
1皿は12本は全部食べきりたい。。。
もうダメなのか。。。
ここまでなのか。。。
諦めかけたその時、視界に入って来たのは水!
水を飲むことで、口の中の甘辛地獄をリセット!圧倒的さっぱり感!
その勢いのまま1皿目完食しました。
審査員のギネスの方にチェックしてもらい、
OKだったので、次の皿が運ばれてくるのを待ちました。
すぐに次の皿が運ばれて来て、
12本のほかほかチキンを見た瞬間、満腹感に襲われました。
このタイミングでこのビジュアルはきつかったです。
ここで作戦を切り替えて、時間をかけてゆっくり食べることに。
あと一口いける。。。あと一口はいける。。。
どんなにお腹いっぱいでも、あと一口はいける作戦で粘りました。
時間はまだまだたっぷりあったので、ゆーっくり食べ続けました。

結果、、、16本!!!

隣の人は24本食べてて、マジで尊敬しました。

エンディングではニワトリの追悼ムービーがそれっぽい音楽と共に流れて、心を痛めつけられました。
そういえばギネスの記録は達成したのかしら?

その後はフライト疲れと、お腹が苦しいのとでそのままホテルに戻りました。
なのでRoboMakerやらなんやらは見逃しました。

Tatonka Challenge楽しかったです。
ぜひ次回も機会があれば挑戦したいです。

Pocket