読者です 読者をやめる 読者になる 読者になる

雑なA型によるクラウドとモバイルと運営と

大阪でJAWS-UG OSAKAとInnovation EGGを運営している人のBLOGです。時々更新します〜

サーバレスアーキテクチャーを運用に適応するために考慮する事【cloudpack大阪BLOG】

PaaSが昔からあるのにLambda+API GateWayが出てサーバレスアーキテクチャーが、もてはやされ出してから時間が経ち、BOT作成人気もあってLambda+API GateWayで試してみた系の話が多くなってきましたが

運用するにあたって考慮すべき話が出てこないので、Lambdaで実現したプログラムを

実際に運用してみて引っかかったり、問題になった部分をちょっと書いてみます。

 

ちなみにサーバレスアーキテクチャーの記事は

や、弊社が出しているLambdaの開発者向けホワイトペーパーは

からダウンロード可能ですので是非みていただければと思います。

 

考慮する点ですが、運用してみた中で、?と思った件があります。

開発時に設定や実装ミスなどもありましたが、エラーが発生せず、
イベントが発火しないケースが存在しました。
問い合わせ時に参考にする記事もあるので一読されることをお勧めします。

 

クラウドではインスタンスが落ちても良い設計をするという話がありますが
サーバレスアーキテクチャーな設計では、エラー時の処理はもちろんの事、
イベントが発火しなかった場合のリカバリーする方法を設計しておく必要があります。

具体的にはイベントが発火しなかった場合、スケジュールの処理などで発火しなかったものを救うなど。
それならいっその事スケジュールの処理で全てすくえば良いって話もありますが、ある程度リアルタイムかつ効率良く処理させれるイベントドリブンな処理は魅力ではあります。

SLA100%ではない現状では、動作しなかった時の検知方法とリカバリー処理は是非とも考えておいたほうがいいです。
※IaaSで実施していた場合も、本当はいろいろあったのですが、

監視方法などが確立され、監視システムのスクリプトなどを

うまく活用して運用してきたのですが、サーバレスアーキテクチャーは

まだこなれてないので、スタンダードな手法がまだ確立されていないのが現状だと思います

 

またシステムの重要度にもよりますが、

Lambdaのメモリ使用量や処理時間などのリソース監視に関しても、注意を払う必要があります。

少しずつメモリ使用量や処理時間が増えていって、ある日突然リソース不足でひたすらエラーに陥いり、あとでリカバリー処理が大変にならないためにも日常のリソース監視

も考える必要があるケースもあります。

 

あとエラーの通知などもよくよく考えずに実装してしまうと、

運用の方がいない場合は開発者の一人24365運用が始まったりします汗。

 

IaaSなどに比べ、開発者にとって、さらにお手軽に実装できてしまう、

PaaSやLambdaですが、運用を考慮した設計と実装を行わないと、

今まで運用している方に押し付けてきたプログラムの未完成さが

フィルターなしにそのまま返ってきます。

 

サーバレスアーキテクチャーやPaaS以上が主流になれば

インフラエンジニアや運用する人は、いらなくなるって極端な話もありますが、

インフラエンジニアや運用してくれる人が、もしいなくなれば、

運用を考慮できない開発エンジニアもその後に淘汰されるってのが

サーバレスアーキテクチャーの案件や、MSP向けのサービスを開発し

運用してきた自分の今の意見です。

 

サーバレスアーキテクチャーで言葉だけではないDevOpsが理解されるようになればと思います。

24365の運用を支える仕組み。PagerDutyを活用する為に【cloudpack大阪BLOG】

最初は自分一人で運用をどう自動化するか?を観点にPgaerDutyの導入から

作業スケジュールのリマインド機能付きslack通知・とあるMSP顧客の各種要望などを
構築/運用業務の傍らにやっていましたが、MSP開発もメンバーが揃いだし、

本格的な開発が可能になってきました。

 

ただ開発者のエゴな車輪の再発明や、

ターゲットが定まってない状態での自動化などの暴挙は行わず

まず運用の可視化や確実性を高めるサービスの導入をひとまず行っています。

※他の現場の可視化が気になって下記勉強会を開催します。よかったら是非

 

cloudpackの運用ではslackをメインにコミュニケーションを行っていますが、
slackの通知はすぐに流れる為に24365で確実に担当者に情報を伝える仕組みとして
PagerDutyをインシデント管理以外も含め活用しています。

非常に便利なPagerDutyですがPagerDuty自体の設定を担当者がミスしていたり、PagerDutyがSLA100%を保証していないのでPagerDutyが正常に稼動しているのか?を監視する必要があります。

その方法として、cloudpackではPagerDutyのサービス障害が発生を想定してアラートメールも併用して冗長化していますが、MSP開発ではアラートメールの内容とPagerDutyの状況を突合させて設定漏れやPagerDutyが正常に動作しているか?を SESの受信とLambdaを利用してチェックし、PagerDutyが正しく動作しているのかを別の観点からチェックする事を可能にしました。

f:id:unioce:20160509134743p:plain

 

MSPはcloudpackのビジネスの根幹です。

お客様に24365のサービスを提供する為にSaaSのサービスを活用するのは必然ですが
利用しているSaaSのサービスが正常に動いていませんでしたって言い訳はお客様にはできないので、MSP開発では日々様々な改善を模索し、開発を行い作成した機能の運用も行っていき、MSPのクオリティを高めていければと思います。

 

 

 ※1 除外設定PD登録のLambdaはアラートメールはあるけどPDに登録されてないものを

PDに登録するLambdaです。

このLambdaで登録されたインシデントはPDに登録された瞬間に自動でクローズされ、突合する時の情報の為だけにPDに登録されます。

この機能により、PDのインシデント登録情報=アラートメールの状態となり、

PDのインシデント登録情報≠アラートメールの場合は漏れとして扱われます。

 

IoTはバズワードか?を確かめたくて開催したInnovation Egg 第六回

IoT AWS CLOUD Google Cloud Platform JAWS-UG SoftLayer Twilio クラウド モバイル 勉強会 基調講演

去年の9月ごろ「IoTはバズワードか?」と色々と思う事がありました。

 

僕の「IoT」が電子工作の域を出なかった理由 - ニートの言葉

なBLOGの投稿がバズっていましたが、自分の経歴である

オープンシステム系開発→制御系開発→モバイル端末開発→

エンタープライズ開発→クラウド運用→運用系開発

と移ってきたときに制御系開発/モバイル端末開発が

シリアルケーブルやLAN・3Gなどに接続されている環境で育った中で

ラズパイにセンサー繋いでクラウドにつなげてクラウド側で様子を見る電子工作の延長に、何ら目新しさを感じず、日本の製品開発のシビアをさを経験した自分からしてみたら、本当に工作レベルの話でした。

なのでIoTをビジネスとして捉える場合、シスコが提唱しシスコの八子さんが

わかりやすく語ってくれるIoEに関しては初めて聴いたときに、

ああこれなら理解できるって感じで、比企のIoTはIoEでした。

 

そして関西のIT業界やデバイスメーカーの方にもIoEを知って欲しいなと思い

八子さんに打診し、

を開催する運びになりました。

9月から数ヶ月たち少し状況は変わり、あれIoTってバズワードでは

無くなってきているなと感覚的に感じる事が身近で多くなり、

9末のSORACOMさんのサービス開始などの発表を受け、IoTの繋げる環境が

容易に手に入る状況になってきました(まだまだLTEのモデムなどは

高い状況にありますが、LTEのIoTやMtoM向けの通信規格だと

非常に安価になるようなので更にどうゆう敷居が低くなります)。

 

そして年初めにはメーカーの多い関西の特性を生かして

IoTの新しいイノベーションが生まれるかわかりませんが、

IoTというキーワードで人や企業が繋がって新しい関係性が作れればと思い

Facebookに「関西オープンIoTグループ」

https://www.facebook.com/groups/447677528759870/

というグループを、関西のハッカソンの盛り上がりを作り出している

元公務員で今は企業された角さんやハンズオン系の勉強会や

生徒にもITを教えている吉田さんと上記グループを作成しました。

※非公開ですが、参加資格はIoTに興味のあって前向きに語り合える良識のある方が

  参加資格です(関西じゃない人も入れますw)。ひねくれたものの見方をして

  問題点だけ語って建設的な発言をされない自己満足な方は参加できません。

 

そして開催二日前のSORACOMさんの

で、C・D・E・Fの各サービスをストリーミング配信で見たときに

更にIoTが身近になったというか、IoTの範囲を超えてIoTを

包み込むようなSORACOMさんのサービスを発表を聴いて

更に色々と考えるようになりました。

※発表時にさくらのIoTも実はSORACOMですって電撃発表を受けた時に

  SORACOMの片山さんとさくらインターネットの小笠原さんが同時に

  登壇する場所を関西で作れたのは非常に胸熱でしたw

f:id:unioce:20160131165214j:plain

 

そして開催当日です。

開催の様子はTwitterで #IEGG で検索していただければ少し様子が

伝わるかと思いますが、 

 

八子 知礼さんの「 IoTで日本から世界に再挑戦!  」

f:id:unioce:20160131164930j:plain

Innovation Egg presen_160130

 

※以降の方の写真は https://www.facebook.com/InnovationEgg/ でw

 

SORACOM-UGから株式会社ソラコムの片山 暁雄 さんの

大阪Innovation egg 第6回資料:SORACOM AirやBeamそして新サービスについて


Twiliojp-ugのcloudpack大阪(iret株式会社)の高橋 慎一さんの

IoTの原点

 

関西おうちハック/GCPUGの株式会社バスキュールの松本 雅博さんの

GCPでお手軽IoTに挑戦


自作デバイスをmyThingsにつなごうインフラからみたDevOps勉強会の株式会社IDCフロンティアの大屋 誠さんの

Innovation egg6 mythings


ハンズラボ株式会社の田部井 一成さんの

ハンズラボの考えるIoT Innovation EGG 第6回 『IoT 今と未来』

 

新規AWS開発系ユーザーグループAWSceanからcloudpack大阪(iret株式会社)の青池 利昭さんの

業務系エンジニアがIoTに触れて感じた事

 

JAWS-UG 関西 IoT専門支部 の 株式会社KYOSOの辻 一郎さんの

[JAWS-UG関西IoT専門支部] IoTで関西のコミュニティをつなぐ


Node-REDユーザー会で日本アイ・ビー・エム株式会社の北瀬 公彦さんの

Try IoT with Node-RED

 

GCPUGでGoogle Incの佐藤 一憲さんの

Having fun with Google Cloud + RasPi // Speaker Deck

 

さくらクラブでさくらインターネット株式会社の小笠原 治さんの
「さくらがIoTってなにやんの?   」

 

と怒涛のセッション内容でした(innovation EGGの状況は他の方がBLOGに書いていただけると期待)。

 

特にGoogleの佐藤さんのデモはただ繋げるではなく、googleのサービスと連携させて

デバイス単体では不可能な内容を見せて頂き、会場からこういうのもあるのか?

と驚きが出ていました。

 

懇親会も盛況で、今までInnovation EGGに来たことがない方も参加しており、

関西以外からも名古屋・東京・四国と遠路はるばる来ていただいていました。

 

懇親会の席も非常に盛り上がったのですが、懇親会の席でデバイスメーカーの方が

「IoTを自分たちがするかを選択できる時代ではない。IoTな世界になった時にどう自分たちの市場を守っていくのか?」と、言われていて、

自身が日本の携帯電話開発をしていて、日本携帯が全盛期のころにiPhoneが現れて、

未完成なAndroidgoogleから発表され自身もAndorid端末の最初のほうに開発をしていた時に、「Androidはいずれ日本の携帯電話市場で日本メーカーの優位性をなくしてしまう。これからはクラウドの時代だからクラウドに移行する」と決断した時に

逆らえないIoTの波の中でどうデバイスメーカーが戦っていくのか?というのに対し

近親感を覚えました。

 

IoTは参加する立場によって様々な入り方があり、WEBの開発者がラズパイを触って始めるのと、デバイス側の方がクラウドによっていくのは全然別のアプローチ・感覚になりますが、WEB側の人とデバイスメーカーの人が入り方は違えど同じエリアに入って

色々と議論し、たとえIoTでなくても新しいinnovationやビジネスが生まれれば Innovation Eggや関西オープンIoTグループは運営する価値はあるのかなと、

この頃自分自身はIoTの定義をあまり考えなくなってきたわけです。

 

Innovation Eggは秋頃にもう一度IoT関連の事をしようかと思っていますが、

デバイスメーカーの人や、まだクラウドに触れていない人のために

開発者向けAWSユーザーグループのAWScean(直近では2月27日にTwiliojp-ugと同時開催)

https://awscean.doorkeeper.jp

 

で、AWS縛りになりますが(範囲を広げると大変だと思うので)、

デバイスメーカーの方含めた非クラウド系の方向けに開催しようかなと思っています。

 

最後に

2000年前半あれほど売れていた日本のモバイルメーカーは

数年で現在の状況になりました。

端末のスペックでは世界一と言われた時もありましたが、携帯電話としては

当時未完成だったAndorid端末にどんどんと侵食されていきました。

日本のセンサーは世界的に精度が高いと言われていますが、

クラウド側とつながったそこそこの精度のデバイスが、現在の状況を

ひっくり返す事は無いとは言えません。

 

IoTはバスワードかどうか?なんて議論は評論家に任せておいて、

自分達のIoTはどうなのか?を自分自身で考えていただければと思います。

 

 

 

 

 

 

 

4桁の方が参加してくれたコミュニティを運営してみて

JAWSUG AWS コミュニティ

長らくやっていたJAWS-UG大阪の支部長を退任しました。

 

今後JAWS-UG大阪はJAWS-UG全国で議論されている?、コアメンバー制度に

結果的にシフトします。

 

そんなのでちょっとJAWS-UG大阪の今までを少しまとめてみたいと思います。

 

自分がコミュニティという存在を意識し出したのは2009年頃のリーマンショック後でした。

関西や地方の景気はひどく落ち込み、自分が所属していたアウトソーシングのIT開発業界も、リストラや個人事業主が廃業したりと非常にひどい状況でした。

仕事がなくなれば今までドル箱だったエンジニアはコストとして扱われ、

非常にひどい状況でした。

比企自身も自分や自分の部下の仕事を確保するために色々と頑張りましたが、

リストラや仕事を取れても競合会社の社員のほうがリストラされるという、

勝者なき泥沼な状況でした。

そんな時にAndroidの会にたまたま参加して、そこで企業の垣根を越えた世界が

展開されており、そこには子会社や下請けなどの多重構造の仕組みはなく、

参加者自体がフラットな状況でした。

このような世界にエンジニアの全てが参加したら、まだいくらかのエンジニアは

職を失った時にでも救われるのではないのだろうか?と考え、

自分の部下とかにコミュニティに参加するように促し、口だけ言ってもついてこないので、自分も一緒に参加するようにしました。

 

その頃ちょうどクラウドの技術が見える範囲にあらわれて、これはエンジニアに対しての福音であると思ったのと自分が携わるモバイル業界はAndroidによって日本メーカーのアドバンテージがなくなると思ったので、あえてクラウドを自分でも進めて行こうと思いました。

 

ただコミュニティに自身が運営しようなんて気持ちはこれっぽっちもなかったのですが

に参加して小島さんや玉川さんの話を聴いて、Google App EnginやAzuruのPaaS派だった比企がIaaSがメインのAWSに興味を持つようになりました。

詳しくは?

に記載しています。

そして

Japan AWS User Group (JAWS) - Osaka勉強会 第1回 : ATND

Japan AWS User Group (JAWS-UG) - Osaka勉強会 第2回 : ATND

Japan AWS User Group (JAWS-UG) - Osaka勉強会 第3回 : ATND

Japan AWS User Group (JAWS-UG) - Osaka勉強会 第4回 : ATND

と開催していきましたが、実は運営としてはあまりうまくいってませんでした。

 

で色々あり、自分と去年亡くなられた益子さんが

Japan AWS User Group (JAWS-UG) - Osaka勉強会 第5回 : ATND

からメインで運営を行うことになりました。

 

益子さんも自分と同じ業界でかつ以前は競合会社のリーダー同士で同じ時代を

生き抜いてきた同志で、クラウドとコミュニティの可能性を理解して、面倒な内容も

行動してくれる人でした。

 

 

そしてJAWS-UG大阪は少し他のJAWS-UGの支部とは毛色の違う感じになりました。

オープンなコミュニティでいろんな人が参加するようにしたいと思ったので、

かなり告知したり存在感をアピールしたので、他のコミュニティからも

浮いた存在として扱われていましたが、そこはあえて見て見ぬふりをしました。

 

Japan AWS User Group (JAWS-UG) - Osaka勉強会 第6回 6/2(土) : ATND

は参加者も増え、AWS芸人の清水さんもLTに参加したりして、講師の地産地消

考え出したのはこの時期ぐらいからでもあります。

そして大型イベントである三都物語2013の開始を控えた、

Japan AWS User Group (JAWS-UG) - Osaka勉強会 第7回 12/15(土) : ATND

は、年末の忘年会シーズンにやってしまい、マズイこのままで大型イベントしたら

やばいなと思っていた時期でもありました。

 

そしてそんな中JAWS-UG初の大型イベント

を仕切って、JAWS-UG神戸の小賀さんやJAWS-UG京都の染田さんや

運営メンバーとともに乗り切って、無事成功することになりました。

現コアメンバーの金春さんや桶谷さんが運営に参加する事になったのも三都物語がきっかけです。

 

三都物語は非常に多くのメンバーで実施しましたが、少人数の運営で

マルチトラックをしたらどうなるんだろう?と試してみたのが

でした。

この頃から運営コストの省力化を考えるようになってきました。

※かなり自身でも負担になってきましたが、

  負担になっていろことを人に任せるのもなと思い、やり続けました。

 

JAWS-UG Osaka 第9回勉強会 Beginners&ServiceProviders 11月2日(土)|

をしたあたりに、本当にしんどくなり、

なれていたイベントレジストから、イベント単位ではなくコミュニティとして

参加者を集める(過去に参加したメンバーにも簡単にアプローチできる)、

JAWS-UG KANSAI | Doorkeeper

に移行しました。

また関西の各支部のJAWS-UGの登録サイトの統合も進めました。

※告知を多くすると、どうしても周りから別の反響も返ってきて辛い部分もありました。

 

どうしたら人が集まるのか?ってのは自分担当だったので、色々と試し、

増えるのと維持のノウハウを貯めることが出来たのが、今では自分の宝です。

 

 

そして

は、他のコミュニティとの調整を実施した経験が、その後の

Innovation EGG <IT系コミュニティ合同•未経験者向け勉強会> | Doorkeeper

の運営のノウハウにつながるようになりました。

ただ、大型イベントに対して、本当に必要なのだろうかというのも

少しずつ考えるようにな出しました。

特に大型イベントの公式サイトに関しては、DoorkeeperとFacebook pageとかで

シンプルにしたほうがよくない?って感じもあり、

また他の地方の運営の方を巻き込むと他の地方のJAWS-UGの活動が

おろそかになって、地方を盛り上げたいのに

ちょっと違うなって違和感も出てもきました(ここはお祭りを一緒に楽しみたいって

地方の方もいますので、あくまで比企の所感です)

 

過去の参加者に容易にアプローチできるDoorkeeprの効果は素晴らしく、

またAWSJAWS-UGの勢い?も出てきて、運営での告知のコストなどもあまりいらなくなってきて、昔はTV大阪さんが好意で貸してくれた場所以外で場所を借りる事は難しかったのですが、今では大阪イノベーションハブさんやエムオーテックスさん・そしてMBSさんなど、たくさんの場所を提供していただける行政や企業がでてきて、

内容さえしっかりしていれば、カジュアルに開催できる基盤と流れが出来たかなと思い、

今回の

は、AWSの新サービスの勢いもありますが、告知から短い期間で

100名以上の方がエントリーするような状況にもなりましたので、

当初目的である

クラウドのエンジニアへの普及(注・AWSとして)

・人が集まるコミュニティ

JAWS-UG大阪としてはそれなりに出来たかなと思ったので、

支部長を継ぐ人も前から言ってましたが、うまく譲れなかったので、

全国で議論されていたコアメンバー制度に乗る形で退任する事に決めました。

 

今後のJAWS-UG大阪がどのようになるかはまだわかりませんが、

たまに自分がやりたいJAWSUGの勉強会があればその時だけ運営するみたいな

形で、通常の運営にはノータッチとなりますので(古参がいるとやりにくいと思うので)、クレーム等は比企には言わないでくださいw。

 

コミュニティをこの4年間ほど運営してみて、結果的に色々な人に巡り会い、

新しい人間関係が生まれ、インフラの経験もないのに、cloudpackに参画して、

忙しいながらもクラウドの最前線を楽しみ充実した毎日を過ごせるようになりました。

 

自分がコミュニティに接する前はオープンソースも嫌い(ソフトが無料という考えが

理解できなかった)でボランティア活動である

コミュニティ運営なんて自分の今までの行き方の中でまったく考えれないものでしたが

今ではやってなければどんな事になっていたのだろう?って感じです。

自分だけではなくコミュニティの中からも、色々な出会いやビジネスが生まれ、

やってよかったな〜と思います。

 

今後は

Innovation EGG <IT系コミュニティ合同•未経験者向け勉強会> | Doorkeeper

の主催や

TwilioJP-UG | Doorkeeper

の大阪コアメンバー兼全国のアドバイザーや

さくらクラブ(総合) | Doorkeeper

のアドバイザーなんかをやっていって、違ったコミュニティの形で

クラウドの普及やIT業界の人が交流・流動的にいきていけるコミュニティを

運営していきたいと思います。

 

とりあえず近々の自分の活動としては、

と、innovation Egg一色ですが、関西のクラウドやIoTがもっともっと盛り上がって

たくさんのIT業界の方に、力になる技術の紹介と交流が生まれる場所を提供できればと思っています。

 

最後にJAWS-UG大阪や関西のイベントに参加していただいた方ありがとうございました。

またJAWS-UGの運営に協力してくれたスタッフや講師の方ありがとうございました。

 

引き続き新しくなるJAWS-UG大阪をよろしくお願いします。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

Amazon API Gateway AWS google apps script Lambda MSP node.js PagerDuty

前回から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のマイクロインスタンス1台の上にいろいろ載せていて

冗長化されてませんが、本来は冗長化する必要があるので大きくお金のかかる部分では

・EC2(t2.micro 1時間 0.02ドル)✖️2=3,456

・RDS(t2.micro・MYSQL・MAZ 1時間 0.052ドル)✖️1=4,492

=7,948円の金額がかかります(データの転送量とかもありますが移行後のシステムも

かかるので除外)

移行後のシステムですがLambdaは無料枠がずっとあり、その範囲で収まる内容ですのでLambdaはお金がかからず、dynamodbがテーブル2つと読み込みのキャパがTOTALで10・書き込みのキャパがTOTALで6で済むので512円(容量代と通信料金は別ですが

そんなに大した額ではないのでここは算出外)と93%OFFなシステムとなります。

※今回のシステムは必ず動く必要があるが負荷はあまりないという特性もあります。

 

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

f:id:unioce:20151009184250p:plain

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に作業を着手したことを伝えれます。

 

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

f:id:unioce:20151009185354p:plain

なケースや

f:id:unioce:20151009185422p:plain

なケースにおいてもほぼ同じシーケンスと同じAPI GatewayAPIで実現する事が可能となり、結果的に処理がシンプルになります。

またこの処理をする事により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

 の主催など仕事も忙しいのにいろいろやっていて、趣味のガンプラも進捗止まっている状況なのでなかなか更新されないかもしれません汗。

少しずつでも解説できればと思いますのでよろしくお願いします。