前回から19日の日が経ちましたがBLOGを書くのをサボっていたのではなく
忙しかったのもありますが
ようやくこのタイトルのシステムが3日間エージングして
ある程度目処が立ってきたのでようやくBLOGを進めます。
※けっしてRe:InventのLambda祭りに乗っかろうと思ったわけではないです・・・汗
今回デプロイツールとしてfluctを使っています。

fluctの使い方は

pict3.hatenablog.com
を見ていただければと思います。

なおJAWSというフレームワークも公開されましたが
どちらも細かい設定は手動で行う必要があるので、
今回は先に試していたfluctを使います(大きな違いは今の所ローカルで動作させるときの違いが
fluctはローカルのサーバーを起動させて、curlなどでアクセスするのに対して
jawsはコマンド一発でlambdaの部分をコールするのですが、JAWSのほうが
putやgetのパラメータの渡し方が見当たらなくソース見ているほど暇もないので
確認していません)。

で、今回は実現するシーケンスを記載したいと思いますが、
その前に今回のリプレイスでどれぐらい金額が変わるのかを説明します(1ドル120円換算で今回は720時間で換算)。
もともとのシステムはEC2のマイクロインスタンス１台の上にいろいろ載せていて
冗長化されてませんが、本来は冗長化する必要があるので大きくお金のかかる部分では

=7,948円の金額がかかります(データの転送量とかもありますが移行後のシステムもかかるので除外)
移行後のシステムですがLambdaは無料枠がずっとあり、その範囲で収まる内容ですのでLambdaはお金がかからず、dynamodbがテーブル2つと読み込みのキャパがTOTALで10・書き込みのキャパがTOTALで6で済むので512円(容量代と通信料金は別ですが
そんなに大した額ではないのでここは算出外)と93%OFFなシステムとなります。
※今回のシステムは必ず動く必要があるが負荷はあまりないという特性もあります。

で、シーケンス図です(この図の番号を元に次回以降説明できたらと思います)。

20151009184250

google apps script(以降gas)のタイマーを起点にgoogleカレンダーの情報を取得。
実施しないといけないスケジュールがあれば、gasからAPI Gateway経由でLambdaを
呼び出して、Pagerdutyにスケジュール情報をインシデントとして登録します。
PagerDutyはwebhooksで再度API Gatwayを呼び出してLambdaで
slackにも通知します(Pagerdutyは全てのユーザーがアカウントを持っていないですし
周知の意味も込めて投稿します。前システムがslackのUIがメインだったので
互換性を保つことも考慮してのことです)

上記シーケンスではslackに表示されたAPI GatewayのURLをクリックすると、
API Gateway経由でLambdaでPagerdutyのAPIをコールして、
Pagerdutyのwebhooksから、API Gateway経由でLambdaでslackに作業を着手したことを伝えれます。

なんかえらく回りくどいなと思うかもしれませんが、

20151009185354

なケースや

20151009185422

なケースにおいてもほぼ同じシーケンスと同じAPI GatewayのAPIで実現する事が可能となり、結果的に処理がシンプルになります。
またこの処理をする事によりAPI Gatewayを二つ用意してAPI Gatewayの冗長化もする(意味はあるのか？w)なんかもできたりします。

Pagerdutyの役割は、スケージュールをインシデントとして確実に管理するのと
Lambdaが昨日まではできなかった、着手されてない作業のリマインド(Cron)の処理を
エスカレーション機能とwebhooksの機能を使う事により実現させる事でした。

ただエージングしていたらLambdaにCronの機能が追加されたって
いかにもクラウドな世界のスピード感ですね汗。
でもこの次にやる事が、LambdaのCronだけではできないのと、タイマー処理は
基本的に自分の中ではイベントドリブンとしてはいけてないと思っているので
別に良いかなと。

シーケンス図は上記のような感じです。
ちなみにこの形になったもう一つの理由がPagerdutyのWEB Hooksの動作にあります・・・

PagerdutyのWeb Hooksは1つづつのインシデントが登録された場合は、
1インシデント 1webhooksなのですが、
タイミングが重なると

  • 2(A・B)インシデント 1webhooks(A・Bが一つのwebhooksで届く)や
  • 2(A・B)インシデント 1webhooks(A・Bが一つのwebhooksで届く) + 1webhooks(Bのみ)
  • 2(A・B)インシデント 1webhooks(A・B) + 1webhooks(A・B)

など、必ず情報は飛んでくるけど、重複する可能性もあるという
どぎつい挙動があります汗。
上記のような挙動を制御をシンプルなAPIで制御したい思惑もあり上記のようなシーケンスになりました。

とりあえず今日はここまで

技術的な部分に関しては次回以降で説明したいところですが、
Soracom Airを使ったシステムの作成と検証や、

jft2015.jaws-ug.jp

や

www.zusaar.com

の登壇や、

innovationegg.doorkeeper.jp

の主催など仕事も忙しいのにいろいろやっていて、趣味のガンプラも進捗止まっている状況なのでなかなか更新されないかもしれません汗。
少しずつでも解説できればと思いますのでよろしくお願いします。

元記事はこちら

「さらばHubot さらばEC2。API GatewayとLambdaで始めるMSPのIT化フェイズ3(その1)【cloudpack 大阪 BLOG】」