AWS Lambda のミニマルなデプロイツール lambroll を書いた

3行で

  • シンプル/ミニマルな Lambda のデプロイツール lambroll を書いてるよ
  • Lambda API 以外は極力触らないやつです
  • 既存 function の移行も簡単です

開発の経緯

AWS Lambda を管理、デプロイするのに数年来 Apex を使っていましたが、最近更新がないと思っていたら案の定というか、残念ながら No longer maintained となってしまいました。

で、代替を探したのですが…

SAM も Serverless もどちらも結局 CloudFormation がお出ましになるし、自分としては関連リソースは別に Terraform で管理しているし、悩ましいなあ、という状況でした。

とはいえ aws-cli だけでやるのもちょっと面倒なことがあり、仕方ないので先週金曜にえいやっと書き始めたのが lambroll です。

github.com

"lamb roll"で検索すると美味しそうですね。

f:id:sfujiwara:20191101010814p:plain

lambroll は何をして、何をしないのか

README に書いてありますが、こんなかんじです。

やること

  • zip archive の作成
  • Lambda 関数の設定とコード、alias、タグの作成、更新

やらないこと

  • 周辺リソースの作成と管理
    • IAM Role とかトリガとか API Gateway とか…
  • Lambda 実行環境用のバイナリ(ネイティブ拡張)のビルド

Lambda の API で叩ける範囲以外は基本しません (S3 へファイル上げる以外)。Runtime や Layer もなにも関知しないので、zip に入れるものは自分でいい感じにビルドしてください。個人的には最近 Go / bash layer しか使わないのでビルドに困ってないというのもあります。

Quick Start

インストールは mac なら brew install fujiwara/tap/lambroll でできます。Linux はリリースバイナリを適当に落としてください。

既存の Lambda 関数を lambroll init で持ってきて管理できます。--download を付けると $LATEST で動いている zip もダウンロードしてきます。

$ mkdir hello
$ cd hello
$ lambroll init --function-name hello --download
2019/10/26 01:19:23 [info] function hello found
2019/10/26 01:19:23 [info] downloading function.zip
2019/10/26 01:19:23 [info] creating function.json
2019/10/26 01:19:23 [info] completed

$ unzip -l function.zip
Archive:  function.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
      408  10-26-2019 00:30   index.js
---------                     -------
      408                     1 file

$ unzip function.zip
Archive:  function.zip
 extracting: index.js

$ rm function.zip

あとは lambroll deploy すると、

  1. カレントディレクトリを zip にまとめる
    • .lambdaignore ファイルで除外指定できます
  2. 関数の設定、コード、タグを更新
  3. alias current を設定

が行われてデプロイされます。簡単ですね!

rollback のための alias 設定は Apex のと互換仕様のつもりです。

command

現在 init, list, deploy, rollback, delete, invoke, archive があります。

function.json

Lambda 関数の設定は function.json に書かれているので、設定を変えたいときはそこをいじってください。構造は CreateFunction API + Tags です。

kayac/go-config による環境変数の展開記法が使えるので、可変にしたい部分に {{ must_env }} {{ env }} 記法を入れておくと、lambroll 実行時の環境変数を埋め込むことができます。stg と prod を別関数にする、などに使ってください。

{
  "Description": "hello function for {{ must_env `ENV` }}",
  "Environment": {
    "Variables": {
      "BAR": "baz",
      "FOO": "{{ env `FOO` `default for FOO` }}"
    }
  },
  "FunctionName": "{{ must_env `ENV` }}-hello",
  "Handler": "index.js",
  "MemorySize": 128,
  "Role": "arn:aws:iam::123456789012:role/hello_lambda_function",
  "Runtime": "nodejs10.x",
  "Tags": {
    "Env": "{{ must_env `ENV` }}"
  },
  "Timeout": 5
}

実際どうなの

一昨日から社内で dog fooding していて、いままで Apex や SAM でデプロイされていたものをどんどこ移行していますが、なにしろものが単純なので普通に動いてます (動かない理由がない)。

Apex の後継とはおこがましいので言いませんが、こういうシンプル (not easy) なやつをお好みなかたはどうぞご利用ください。

ecspresso で設定ファイル生成と CodeDeploy による Blue/Green デプロイに対応した

ecspresso は筆者が開発している Amazon ECS 用のデプロイツールです。

github.com

最近 AWS DevDay Tokyo 2019 の「第1回 AWS Fargate かんたんデプロイ選手権」でも紹介していただいて、気をよくして最近あれこれ機能追加をしていたのでそのご紹介です。

speakerdeck.com

分かりやすい導入記事をクラスメソッドさんの blog で書いていただきましたのでこちらもどうぞ。

dev.classmethod.jp

設定ファイル生成機能

ecspresso init で、既存の ECS サービスの情報を引っこ抜いて定義ファイルを生成し、そのまま ecspresso deploy できるようになりました。(v0.11)

README の Quick Start にもあるように、region, cluster, service, config を指定して (適切な credential がある状態で) 実行すると、以下の3ファイルをカレントディレクトリに生成します。

  • ecspresso の設定ファイル
  • ECS サービスの定義ファイル
  • サービスに設定されているタスク定義ファイル

特に動作しているサービスに影響はしないので、稼働中のサービスに対して実行しても問題ありません。

$ ecspresso init --region ap-northeast-1 --cluster default --service myservice --config config.yaml
2019/10/12 01:31:48 myservice/default save service definition to ecs-service-def.json
2019/10/12 01:31:48 myservice/default save task definition to ecs-task-def.json
2019/10/12 01:31:48 myservice/default save config to config.yaml

その後、そのまま deploy を行うと、新しいタスク定義を登録してサービスを更新し、デプロイが行われます。簡単!

$ ecspresso deploy --config config.yaml

実運用するには、タスク定義ファイルに {{ must_env "IMAGE_TAG" }} のような記法でデプロイごとに更新されるであろう部分に環境変数を展開するように記述しておき、実行時の環境変数設定でタスクを更新するのがお勧めです。

他のツールや、AWSコンソールからポチポチで作ってしまった ECS サービスやタスク定義を、簡単にコードによる管理に落とし込むことができます。もし ecspresso の使用をやめるとしても特に何も起こらないので、気軽にお試しいただけます。

CodeDeploy による Blue/Green デプロイに対応

これまで ECS の機能によるローリングデプロイのみに対応していましたが、Blue/Green デプロイを行いたいという要望があったので、AWS CodeDeploy によるデプロイにも対応しました。(v0.12)

{
  "deploymentController": {
    "type": "CODE_DEPLOY"
  },

サービス定義で deploymentController.type = "CODE_DEPLOY" となっている場合、ecspresso deploy を実行すると CodeDeploy に新しい Deployment を作成します。その後の進行は CodeDeploy 側で行われます。

$ ecspresso deploy --config config.yaml --rollback-events DEPLOYMENT_FAILURE
2019/10/15 22:47:07 myService/default Starting deploy
Service: myService
Cluster: default
TaskDefinition: myService:5
TaskSets:
   PRIMARY myService:5 desired:1 pending:0 running:1
Events:
2019/10/15 22:47:08 myService/default Creating a new task definition by ecs-task-def.json
2019/10/15 22:47:08 myService/default Registering a new task definition...
2019/10/15 22:47:08 myService/default Task definition is registered myService:6
2019/10/15 22:47:08 myService/default desired count: 1
2019/10/15 22:47:09 myService/default Deployment d-XXXXXXXXX is created on CodeDeploy
2019/10/15 22:47:09 myService/default https://ap-northeast-1.console.aws.amazon.com/codesuite/codedeploy/deployments/d-XXXXXXXXX?region=ap-northeast-1

ログはこんな感じになり、最後に CodeDeploy の AWS Console の URL が出力されています。端末で実行していて、かつ open コマンドが存在する場合には、open $url を実行することでブラウザの画面が開きます。

ecspresso create でサービスを新規作成する場合には、CodeDeploy のリソース (Application, DeploymentGroup) は特に作成はしないので、なんらかの方法で (コンソールポチでも aws cli でも Terraform でも CloudFormation でもお好みで) 各自作成してください。

ecspresso deploy 時にはサービスに対応する CodeDeploy Application / DeploymentGroup を自動的に見つけて、それに対して新規デプロイを発行します。


ということで、ecspresso の最近の新機能の紹介でした。ECS のデプロイ、タスク定義管理に悩んでいる方がいらっしゃいましたら、どうぞご利用ください。

WEB+DB Press vol.111 Perl Hackers Hub に「AWS X-Rayによる分散トレーシング」を寄稿しました

技術評論社 WEB+DB Press vol.111 の連載 Perl Hackers Hub に、「AWS X-Rayによる分散トレーシング……マイクロサービスのボトルネック,障害箇所の特定」という記事を書きました。

WEB+DB PRESS Vol.111

WEB+DB PRESS Vol.111

  • 作者: 松田明,y-yagi,佐藤建太,夜道,村田賢太,伊藤英明,見川孝太,新井剛,関陽介,海老原圭吾,長田洸明,大原壯太,藤原俊一郎,松本宏太,末永恭正,久保田祐史,牧大輔,笹田耕一,竹馬光太郎,池田拓司,はまちや2,竹原
  • 出版社/メーカー: 技術評論社
  • 発売日: 2019/06/24
  • メディア: 単行本
  • この商品を含むブログを見る

内容は1月にあった YAPC::Tokyo の発表をベースにしたものです。

sfujiwara.hatenablog.com

YAPC での発表をしたときの印象で、どうも分散トレーシングはそこまでメジャーじゃなさそうだぞ、ということで、Perl の連載枠ですが前半半分は分散トレーシングというものの概念、AWS X-Ray についての説明に割きました。なので、Perl 以外の言語をお使いのかたでも、分散トレーシングをなんとなく把握してみたいというかたにも参考になる内容になっていると思います。

後半は ISUCON 8 の Perl 実装を X-Ray で解析して可視化するという内容です。今年も ISUCON の季節がもうすぐやってきますね。ISUCON 9 の攻略のためにも是非参考にしていただければと思います。


さらに今号から1年間の予定で、勤務しているカヤックの SRE チーム持ち回りで「インフラ運用のアイデア&テクニック ── 小さなチームでマネージドサービスを活用」という連載が始まりました。

ここ数年のインフラ連載枠は、大規模!最先端!みたいな雰囲気が多かったと思うのですが、今年はそこまで先端でも大規模でもないけど少人数でクラウドを上手く活用していこう、レガシーなのもいい感じにマイグレーションしていこう、みたいな雰囲気になる計画です。

こちらも是非ごひいきにお願いします。


そのほかの記事も、Rails 6 (カヤックでは受託案件のサーバはRailsが多いので気になります)、Julia (データ解析との親和性が高そう)、見える化大作戦 (アナログも大事だなあと)、などなど、毎度ながら充実の記事ですので、是非お買い求めください。

Amazon ECS タスク定義のコンテナ依存関係を可視化する

Amazon ECS のタスク定義には、タスク内のコンテナの起動と終了の順序を制御する依存関係が定義できます。

docs.aws.amazon.com

アプリケーションのコンテナと、アプリケーションが依存しているミドルウェアのコンテナがあった場合、依存を定義すると

  • タスク開始時にミドルウェアが起動してからアプリケーションが起動する
  • タスク終了時にアプリケーションが停止してからミドルウェアが停止する

というような制御が可能です。

graphviz による可視化

しかし依存関係が複雑になると、JSON で文字列で書いただけでは実際にどう依存しているのかがよく分からないし、間違ってループを作ってしまうと起動できないので事前に確認したい、ということで可視化してみました。

f:id:sfujiwara:20190529144138p:plain

これはとあるアプリケーションタスクの依存関係を、task definition の JSON から graphviz 用の .dot ファイルを生成して画像にしたものです。

gist.github.com

taskdef の JSON を引数にして実行すると .dot を吐き出すので、それを dot コマンドで画像化します。

$ perl graph-depends-on.pl  app.json > app.dot
$ dot -Tpng app.dot -o app.png

グラフの各ノードがコンテナで、定義された dependsOn に従ってノードが接続されています。

内部的にそれぞれ必要そうな依存を全て記述するとこうなったのですが、しかしこれだと ECS task が起動しないということが判明。具体的には xray コンテナが起動したあと、他のコンテナが PENDING のまま起動できない状態になりました。

各コンテナから依存先に到達する経路が一意でないのがよくないのかと思いついて、依存を整理したのが次の画像です。

f:id:sfujiwara:20190529144154p:plain

これは無事に起動できました。

まとめ

  • Amazon ECS のコンテナ依存関係は依存を一意にしないと起動できないことがある
  • 依存を可視化できると便利
  • graphviz で可視化するスクリプトPerlRuby で書いたのでご利用ください

Stretcher をご利用中のかたに大切なお知らせ (S3 Signature V2廃止の件)

拙作の pull 型デプロイツール Stretcher をご利用中のかたに大切なお知らせです。

Amazon S3のAWS署名バーション2が、2019年6月24日をもって廃止されます

dev.classmethod.jp

Stretcher v0.x は Amazon S3 からのファイル取得に AdRoll/goamz を利用しており、このライブラリは Signature V2 を使用しているため、2019年6月24日以降 S3 からのファイル取得に失敗するようになります。

現状でも Signature V4のみサポートしているリージョン (us-east-2など) に対して実行すると、以下のようなエラーメッセージで失敗することが確認されています。

Load manifest failed: cannot detect valid credentials or region

ということで、この機に公式 SDK aws-sdk-go に実装を切り替えた v1.0.0 をリリースします。

現在 rc1 を提供していますので、ご利用中のかたは検証の上バージョンアップをお願いします。

(2019-03-17 追記) v1.0.0 をリリースしました。 github.com

基本的に互換性は保っていますが、credential の読みこみを自前のコードから SDK に変更した関係で一部非互換がある可能性があります。 現時点で確認されている非互換としては以下のものがあります。

  • $HOME が設定されていない状態で ~/.aws/credentials の認証情報を読み取れない
    • ホームディレクトリが解決できないため
    • 実行時に適切な $HOME を設定すれば解消します
    • 古い版では mitchellh/go-homedir で自前で解決していたので公式 SDK になって挙動が変わりました

他に何か問題がありましたら https://github.com/fujiwara/stretcher/ まで issue か、Twitter で @fujiwara までお知らせください。

github.com 報告していただいた varusan さん、ありがとうございました!

YAPC::Tokyo 2019でAWS X-Rayによる分散トレーシングの発表をしました

2019年1月26日に開催された YAPC::Tokyo 2019 にて、「Perlでも分散トレーシングしたい! - AWS::XRayによる解析とその実装」というタイトルの最後で発表してきました。

yapcjapan.org

発表資料はこちらです。

speakerdeck.com

ほとんどのクラウドベンダーやマネージドサービスで Perl SDK が提供されていない昨今ですが、AWS X-RayPerl で使いたいがために AWS::XRay を書いたよ、例として ISUCON 8 本選問題を解析してみたよ、という話です。

X-Ray は分散システムでなくても (従来型の RDBMS を使うだけの Web アプリケーションでも) パフォーマンス解析に有用で、使い始めるのに手間もないので興味を持ってもらえた人がいたら幸いです。

会場で挙手してもらった感じでも分散トレーシング自体それほど広く認知されてないようで、そのへんもあってちょっと集客がうまくいかなかったな… というのが反省点ですね。タイトルや内容の工夫の使用がもうちょっとできた気がします。


今回の YAPC でもう7回目の発表で、自分にとっての故郷的な感が強いカンファレンスです。

アクティブな CPAN Author が年々減っていたりと、今後開発のメイン言語として Perl が採用されることはどんどん減っていく流れは明白で寂しい限りなんですが、それでも400人近い人が集まって、Perl入学式などで入門してくる若者もいて、活気があって楽しかったですね。Songmuさんの男泣きにはぐっと来るものがありました。

次回、京都であるかも知れないということなので、楽しみにしています!

graceful restart できない daemon の再起動時のダウンタイムを HAProxy でリトライして救う

とあるネットワーク(Web)サーバがありまして。

  • graceful restart できない
  • graceful stop はできる
    • 処理中のものは全て処理し終わってから終了する
  • 再起動は数秒で完了する

という性質のものを、稼働中に再起動するとダウンタイムがでてしまうのをなんとか誤魔化したかったのです。

最初は nginx から proxy しているところで、繋がらなかったら何秒かおいて何回までリトライ、みたいな設定ができないか探したんですが見つからず、HAProxy を調べたら以下のような設定でできたのでメモ。

frontend absorber
    mode tcp
    default_backend upstream
    bind *:9999

backend upstream
    mode tcp
    server localhost localhost:8888 weight 1
    retries 10

retries 10 で、接続できなかった場合には 1秒間隔(1秒以下のtimeout connect が指定されていればその間隔) で10回までリトライする、という挙動になります。これで10秒以内に再起動できれば救済可能です。

適当に ab でリクエストを流し続けながら再起動してみてもエラーはでなかったので、大丈夫でしょう。

(2018-01-15 18:15 redispatch は関係なく、再試行間隔は timeout connect に依存していたので修正しました)