カンファレンスは過去にServerlessConf Tokyo 2016をやったとこと同じ会場。
他のServerless DaysにならってPaperCallを使って募集します。選択バイアスを最小にするために匿名化して応募を受け付けれる為、コンテンツの内容によって判断しやすしようという試みです。
3つのトーク尺とワークショップを募集しているのでどしどし応募を〜。
今回はちょっと喋ってみたいけど不安のある方・初めての方・自身のない方に対してメンター制度を導入しており、応募前のCFPレビューやスピーキングの指導も行えますので相談可能だったりします。
イベントを成功させるには皆さんのお力が必要です。
スタックやスポンサーをしてくださる方は是非ともご連絡ください!!
先日、Serverless Daysの生みの親であるPaul Johnstonによって新しいサーバーレスに関するパラダイムが提唱されました。(日本語訳)
サーバーレスは教義であり、テクノロジーではない
単に利用方法だけではなく、Serverless Daysではこういう一歩掘り下げたコンテキストをカバーできればなという思いです。
乞うご期待ですね!
]]>元々JeffConfという名でヨーロッパ各地で数回開催されていたサーバーレスのカンファレンスですが、Severless Daysに改名されました。Serverless Confみたいな大規模カンファレンスではなく、「One Day. One Track. One Community.」というスローガンの元で行われるローカルコミュニティ主導の地域密着イベントです。奇しくも去年のServerlessConf Parisの翌日にJeffConf Hamburgが開催されたのですが、スピーカーの懇親会があってスケジュール的に断念したので、今回改めて発表という形で参加できたのは感慨深かったです。
場所は去年の美術館から変更されてサッカースタジアムの施設を利用
ぎゅうぎゅうに詰められた会場がアットホームで良い感じ
Keynoteは安定のYan Cuiさん。サーバーレスに関わる都市伝説を各個撃破してたw
中でも名言は
スピーカーは世界中から招待。覚えてるだけで
ご飯がドイツらしくビーガンだったけど美味!
以下ClaireさんによるSketch Note!
技術的な発表が多い中、私のタイトルはServerless Communitiesといって、サーバーレスのコミュニティにフォーカスした内容でした。日本でのサーバーレスコミュニティの運営に関わってきて得た経験、知見、活動などを共有し、コミュニティ参加の意義を(少し)エモく訴えて、他国のコミュニティやエンジニア達を少しでも刺激・喚起できればなという思いでした。
ここではコミュニティ参加の意義や思いは詳細に書きませんが、一つだけ。
Give to the community. It will give back to you.
どんな些細な形でも良いのでコミュニティ活動に関われば、きっと将来いろんな思わぬ形でそれ以上リターンとして還ってきます。今の自分を(技術的にも仕事的にも)支えてるのは、振り返ればそういった活動から生まれた結果・繋がりだったりするので、是非皆さんにも体験して頂ければなと。(別にそれ目的で関わる必要はなく、むしろプロセス自体が面白いので、そんな事忘れて楽しめば良いと思います)
そして、その繋がりが国を跨いで世界各国まで拡大すればきっと見える景色や可能性も違ってくるでしょう。
世界中に広がっていくDaysの予定地!
というわけで今年は日本でServerless Confではなく、方向性を変えてServerless Daysを開催します。スピーカー、スタッフ、スポンサー大募集なので、是非とも協力をお願いします!東京・福岡の2都市開催で秋頃開催予定です!
今年も広かった。本当に広かった。。
Microservicesというテーマで昨今の潮流に沿ってる感じで非常に楽しめた。
今年は短く4時間になっていて、2回開催。またWernerのキーノートと重なって、意識を拡張しながらの作業だった。
難易度によって課題がレベル分けされていて、それをチーム内で分けてクリアしていくゲーム。Security Forensics的な要素が面白かった。
今回はJAWS-UG関西の仲間と共に穴場的ロケーションから鑑賞。
以下、気になった発表だけ抜粋。
DJは2014年以来、2回目のSkrillex
場所は参加者が増大したので少し離れた場所にあるLas Vegas Festival Groundsにバスで移動。
先月、たまたまアフリカに行く機会があったのでその時期に行われていたルワンダのTransform Africa Summit (TFA)に参加してきました。今回はコミュニティ仲間の@yoshidashingoさん、@horike37さん、@jkudoさんと共に(私だけ南アフリカより現地集合)行動を共にしました。
そもそもなんでルワンダに行こうという事になったと言うと、IT立国を目指していてアフリカのシンガポール的な位置づけになろうとしていてテック系のスタートアップが多く立ち上がっていて気になったからです。中でも有名なのが道路が未整備な農村地区の病院にドローンで血液を空輸するZipelineやDMMが買収したDMM Heheがあって面白そうと感じたからです。
汚職が少なく治安もよく、テックスタートアップの為に法改正までするルワンダを見てみたいなって話してた所にちょうどTFAが開催されるで行ってみようという流れでした。
紙幣。教育とITに力を入れているのがよく分かる。
首都キガリの中心にあるカンファレンスセンター。モダンな感じ。
少し外れるとまだまだ発展途上感。
日本のJAICAが支援しているスタートアップのインキュベーションプログラム。
うーーん。拍子抜け。皆さんプレゼンがお下手で、ビジネス戦略やそもそものマーケット分析が全然ダメダメで正直小学生の宿題みたいな内容でした。。水漏れ検知システム、節電システム、自動卵孵化装置等。。もっと世界の勉強が必要なんじゃないかと。
後で知ったのが、250チームからの選抜だと思っていたら最初の8チームでした。この先大丈夫だろうか。
マネーの虎みたいなピッチイベント。こちらはより洗練されていて面白かった!
最後の女性が一番パッションを持ってビジョンや取り組みを語たり、全員から出資やメンタリングのオファーが出てきて感動。
インフラが未熟や信頼できない国ではブロックチェーンによって信頼を分散させる方がより堅牢なシステムになるのはなるほどなぁという印象。コンテキストにうまく当てはまれば価値が発揮されるケースがあるんだと改めて理解。
参考までに同行者仲間のブログはこちら
]]>タイトルはAccelerating DevOps with Serverlessで、DevOpsを手助けする為にServerlessを使って解決したストーリーや仕組み。
内容としてはシンプルでgithubのbranchに応じて、テスト環境用のECSクラスタ内にrandom portでALBにtarget group, listenerを割り当ててservice作ってコンテナを配置するだけです。branch delete時にはtaskを停止し、逆順に削除していきます。通知はSNSでslack等へ連携可能。
少し特色があるとすれば、serviceを作成したりtaskを停止するのにかなり時間を要する場合があるので、単一のlambdaではなくstep functionsで制御した事ですかね。今回、serverless frameworkのstep functions pluginのおかげでstate machine dataをjsonで書かなくて済んだので作者のhorikeさんには感謝です。
発表した内容のモノは現在、複数プロジェクトで使えるようになるべく汎用的な作りにしてECS deityとして公開しています。参考にでもなれば。
https://github.com/ijin/ecs-deity
尚、GitHub eventによる自動デプロイだと毎回煩わしい場合もある(特定のbranch prefixが対象であるにせよ)ので、slackによるchatops手動デプロイも実装中です。
と、まあやってる事はそんなに難しくないので、海外カンファレンスのCFPがあれば誰でも気軽に応募してみると良いと思います!
やはり、serverlessだとログ周りが様々なCloudWatch logsのlog streamsに分散(api gw, lambda, step functions)しているので、トレーシングがしんどかったりしたけど今回のConfで何度も取り上げられたトピックがObervabilityだったので皆同様に苦労しているんだなぁと感じました。ブースにもその解決に取り込もうとしている企業がいくつかいたので、今後に期待ですね。
この辺は一緒に行ったyoshidashingoさんがブログでよく考察してくれています。
後、Keynote SpeakerのYan Cuiさんのトークが重厚で実に素晴らしかったのでYouTubeに上がったら是非観てください。内容もテンポもスライドも勉強になります。
]]>
例によって、帰国直後の体験談の発表
まず、何よりもGame Day!もはやこれに出れれば8割型満足。。内容としてはいろんなサービスを使うようになってて結構凝ってた。
去年の運営チームとは別になったらしいので中身も毛色が少し違ってた。
今年は部屋でゆったりと。
怒涛のリリースラッシュ!
前日に引き続き、リリースラッシュを構えていたのにちょっとだけ発表してWernerの熱い想いを語る独壇場だった。。
いろんな要素やサービスが詰まったハッカソン。初めて触るサービスもあって楽しかった。
VenitienからAriaまでの道のり。。長い。
メインDJはDJ Snake。プレイ自体は30分ぐらいは楽しめたかな。。好み違った。
Day 1の終わりに着いて、ほぼDay 2のみ
Quineおじさんによるウロボロス的lambda実装のお話。思考実験としては面白かった。
最後にRAP!!!新しいwww
base
やcompare
とで混乱しそうになるので、ChatOpsを導入して効率化してみました。
Slackと連携できるボットにはrubotyを選択。
プラグイン周りではruboty-githubがあるけど、微妙に要求に応えれなかったので少し拡張したruboty-github_pr_releaseを作りました。久々のgem公開。
1
|
|
pull requestを作成。それまでmergeしたfeature branch等のタイトルが集約される
1
|
|
pull request作成後に新たなコミットを取り込む時やタイトルを変更したい時
1
|
|
pull requestをmergeしてデプロイ
1
|
|
ruboty-aliasやruboty-scoped_aliasを使うとさらにコマンドを短縮して便利です。scopedにすると部屋毎にプロジェクトを割り当てたりも可能。
1 2 |
|
簡単!
ほとんど作り終えたところでほぼ同じ機能を持ったincrements/ruboty-qiita-githubに気づいたけど、気にせずリリースしちゃった。一応merge周りはこっちの方が若干楽なので。。
]]>帰国直後にJAWS-UG横浜支部で体験談を発表したのですっかり忘れてた。。
今年は例年より開催が1ヶ月遅く、且つ期間が長め(11/28〜12/2)でした。 参加人数は過去最大規模で32,000人。PalazzoとVenetianのホテルに収まらなくて、新たにちょっと離れたMirageも借りることに。また、今年から登録制の運用が厳格になったので、飛び込みは行列に並ぶ必要がありました。
お題は去年のUnicorn企業のシナリオを拡張したけど、テーマは今年の流行りを反映した内容。 運用コストやパフォーマンスが加味され、チーム感でスコアを競うんだけど今年は新たにボーナスステージが用意されたりして全体的にいろいろ最適化されてた。
80チーム以上で過去最大規模。また、奇しくもGame Day初回参加時に同じチームメンバーで友人となった人とチームに!
8時間の長丁場だったけど、もうこれだけで大変満足して後はもういいやって気分に。
ちなみにオンライン登録が間に合わなくて、当日飛び込み参加だけどなんとかギリギリ最後の一人では入れた。
AWS Vice PresidentのJames Hamilton氏によるデータセンターの詳細が話された。初公開情報が多く、パッションが強くて聞いてて飽きなかった。
新サービスもちょこっと。
Andy Jessy (AWS CEO)により発表。テーマは「Superpower」
Werner Vogels (AWS CTO)による発表。テーマは「Transformation」
Lambdaのrubyかgo対応を期待してたのに、ちょっとがっかり。。
サーバーレスをお題にしたワークショップ。コピペだけでちょっと面白みがなかった。。
詳しくはこちら
2016年EDMのベストDJに選ばれた若手のMartin Garrix。また金積んだな〜。
のんびり
暇だったのでベータ試験を全部受けた。
途中、開始トラブルがあって、担当マネージャからテスト問題誕生秘話を聞いたり、クーポンもらったりした。
少し前に話題の「サーバーレス」アーキテクチャに関するイベントであるServerlessConf Tokyo 2016をお手伝いしたことから、ロンドン版開催のお誘いが来たので行ってみました。
開催場所はetc.venuesという施設。
サーバーレスについてのカンファレンスなのに、キーノートでジャブ撃ちまくりが面白かった。
iRobotやCloud Custodianを公開したCapitalOneのセッションも面白かったけど、一番は元ParseのエンジニアであるCharity Majorsのセッション(Serverlessness, NoOps and the Tooth Fairy)。サーバーレスを採用しても結局サービスの責任は自分で負わないといけない啓蒙的な話を様々な例を交えつつ、パッションを持って話してくれた。
LTという割にはミニセッションな感じ。日本のLTみたいな笑い所はあまりなし。最後の火星探査機もどきのやつは少し興味深かったけど。
興味深かったのはnewrelic apm風なlambda専用の解析ツールIOPipeを作ってる人によるOps for NoOpsやRealmのFounderによるServerless in an Offline-First world。どちらも自社プロダクトを紹介しつつも結構サーバーレスアーキテクチャでの設計やオペレーションを深掘りした話だった。他はZappaの作者によるGlobally Available Serverless Architecturesがテンポよく進んで見てて飽きなかった。
MSの人達によるAzureの高速棒読み寸劇が笑えた。
セッションもまあまあ面白かったりしたけど、Serverless Framework等各種ツールの作者と直接話したり、各国のエンジニアとサービス運用について細かく議論できるのが有意義でした。ヨーロッパ圏の人がメインだけど、意外とアメリカからも沢山来てて終始盛り上がりました。日本からはServerlessConf Tokyoの主催者のセクションナイン吉田さんやもっぱらさん等が来英した他、クラスメソッドのベルリンリージョンにいる吉田さんがわざわざメソりに来てて、ノルマ大変そうだなぁと思ったり。
後、LTに関しては日本の方が絶対レベルが上だと思う!自社プロダクトの紹介とかやめて。。
ちなみにセッションの動画はここから見れます。
カンファレンスの雰囲気。インタビューされちゃいました。
]]>お題は基本的に去年のre:Inventでやったのを若干チューニングしたやつ。 詳細は今後また別のところで開催される可能性があるので、その時の参加者の為に伏せておきます。
競技中はそれぞれのチームのスコアがリアルタイムで見れるダッシュボードがあって白熱した様子が伝わってました。
これはこれで楽しいんですが、何かが足りない感じ。。。
そう、グラフです!!
参加チームの白熱したバトル(順位の入れ替え等)を時系列で表示し、戦いの軌跡をビジュアライズするアレです。ISUCONでもよく見慣れたあの遷移するグラフがなかったのです!
開始してから気づきました。。
ダッシュボードの作りを見てみると jQuery
と React.js
を使っている模様。ならば、どこかでendpointを叩いてjsonを取得しているはずなので、いろいろ探したところ、それらしいのがありました。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
こうなれば話は簡単で後は返却されるjsonを解析して、定期的にcallしてplotしていけば良いだけです。
グラフを描画するサーバを用意するのはしんどいので、カスタムメトリックスが作成できる監視サービスを使いました。 最初はMackerelをと思ったけど、独自グラフを一般公開する設定がなさそうだったのでDatadogを採用。
Datadogでカスタムメトリックスを送るにはAPIを直接叩くよりは、StatsD経由で送信した方が楽なのでrubyでサクっと適当に記述。
1 2 3 4 5 6 |
|
公開ダッシュボードを作成するには TimeBoard
ではなく ScreenBoard
を選択し、後は必要そうなグラフを追加していくだけ。
グラフ自体はGUIで作っても良いし、jsonで記述可能なので結構柔軟で素敵です。
1 2 3 4 5 6 7 8 9 10 11 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
できあがったグラフはこんな感じ。 高負荷発生等のイベント時の対応との比較もできて見やすいと思います。
これで各チームのポジション等を伝えやすくなりました。
というわけで優勝したチーム初老丸、おめでとうございます!
今回は競技の途中から実装しちゃったので次回は最初から用意しておきたいと思います。
(※)実は去年のISUCONの時も似たような事をやってましたね。。
]]>ちなみに行く事になった経緯は後日のJAWS-UGおコンテナ支部 #5でLTしてきました。
パッション大事!
以下、トゥギャッター風に。
場所はシアトルのWashington State Convention Center。何気にこの地に訪れるのは初。
Welcome to DockerCon 2016!
企業ブース
Welcome Party
Bar
ぞろぞろ
The Golden Ticket: Docker and High Security Microservices
Microservices + Events + Docker = A Perfect Trio
Thinking Inside the Container: A Continuous Delivery Story
最後はシアトルの名所(?)、Space Needleでの貸切パーティー
中でもワイワイ
個人的には、とある企業でのDockerのユースケースを演じる漫才が面白かった。
AzureのCTO
ADPのCTO
Making Friendly Microservices
Sharding Containers: Make Go Apps Computer-Friendly Again
Closing General Session: Moby Dock’s Cool Hacks
Serverless Dockerが面白かった。
Docker on Drones
世界各国のエンジニアと話せて、Dockerに対する熱量や動向を肌感覚で感じとれて非常に有意義な旅でした。以前のChefConfやHashiConfもそうだけど、気になる技術やトレンドがあればTechカンファレンスに直接乗り込んで見るのが一番効率的なので、今後も継続してどこかに参加するようにしたいです。
Thank you!
]]>selection_pattern
のpull requestがmergeされました。
今まではAPI GWをInfrastructure As Codeで構築するにあたって複数のintegration responseパターンを返却できないのがネックだったのが、これでようやく解決。途中までTerraformで作って、その後に以下のようにawscliで追加するというちょっと煩わしい手順でした。
1 2 3 |
|
というわけで、早速実験。お題は以前紹介したElastic Beanstalk ssh用のAPI GWで。
まずは、master
にmergeされた開発版Terraformのビルド。やり方はこちら。
1 2 |
|
API GWのterraform化はこんな感じで。
(*) permissionはlambda作成後に許可
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 |
|
できた!
リソースを作成するのに並列処理が出来なかったり、依存関係がまだうまく対応できてないので、depends_on
を駆使する必要があるのが若干まだ面倒。ない場合は、BadRequestException: Unable to complete operation due to concurrent modification. Please try again later
やBadRequestException: No integration defined for method status code: 400
等のエラーが発生する。
CORS等の設定するする際にはAccess-Control-Allow-Origin
等のヘッダーをMethodやIntegrationのResponse Headerに設定をする必要があるけど、.
の扱い問題で未対応(#2143)。それまではawscliで以下のようにすると事で回避。
1
|
|
Issueはこの前上げたので(#6092)、ウォッチしておくと良い。
API Gatewayはresource
, method
, integration
, method response
、integration response
等を記述しないといけないので、どうしてもコードが多くになってしまう事からSwaggerでやった方が楽だったりするかも。ただ、その場合はInfrastructure as YAMLになってしまうけど。。また、YAMLは整形してからimportする必要があったりするので、その辺は諸々トレードオフかなぁ。
1 2 3 |
|
どのコミットリビジョンを使っているか簡単に分かるように、versionにgitのcommit hashを指定。
1
|
|
make devすると全pluginやproviderがコンパイルされ、非常に時間がかかる(特に最近は対応範囲の広がりが著しく、生成されるバイナリの総容量が増加傾向)。 よって、特定のproviderを指定して時間短縮する。以下はaws providerで作業している場合。
1 2 3 4 5 6 7 |
|
1 2 |
|
Happy Terraforming!
]]>ssh
やgit
を使えたら便利!思ったけど、そもそもバイナリ自体が入ってない上にパッケージのインストールが出来ないので回避方法を悩んでいたところ、幸いそれぞれPython nativeの実装があったので先人の肩に乗っかる事で事無きを得ました。
SSHはParamikoというライブラリを利用。s3上にSSE-KMSで暗号化されたキーファイルをダウンロードし、それを使ってサーバと認証しログイン。
注意点
Gitはdulwich
というライブラリを利用。sshプロトコルの場合、デフォルトではシステム上のsshが利用されるのでPython版のParamikoSSHVendor
クラスを使えばすんなりいくと思いきや、キーファイル指定が出来なかったのでそこを少し改変。また、Lambda上での特殊な環境の為かsys.stderr
のencode周りがうまく検出されなかったので、dulwich.porcelain.push
methodも若干修正。
Paramikoを使っているので、上記同様パッケージ作成はLinux上で。
以下はprivate repositoryをclone後、別branchに新規ファイルを追加後にcommitし、githubへpushする例。
それでは、良いLambdaライフを!
]]>2016/1/14
現在、AWS Lambdaにはなんとリージョン毎!にアップロードできるパッケージの合計サイズがたったの1.5GBという悲しい制限があります。特にlibraryを同包したり、versioningを使ったりしてCIをガンガン回してると、結構すぐこの上限に達してしまいがちです。そこで、Lambdaの総容量はAWSコンソール上には表示されるものの、トラッキングし辛いので監視する仕組みを作ってみました。
LambdaのScheduled Eventsを使って、ListFunctions
とListVersionsByFunction
APIを叩いて、個別functionのCodeSize
をサマって、PutMetricData
でCloudWatchに投げて、Alarm設定してるだけ。
(*) 2016/1/26
追記:@marcy_teruiさんからのご指摘でVersionsの容量計算が抜けてました。ありがとうございます。
といっても、今後別アカウントでいちいち設定(IAM role&policy、Lambda、SNS、CloudWatch)するのも非常に面倒くさいので、今回はCloudFormation Designerを使って、ほぼ一発で環境を再現できるようにしました。
Designerではこんな感じ。心なしか、jsonの苦痛が多少楽になったような。。後、Propertyの補完機能は良いけどショートカットがCmd+Space
なのでSpotlightさんがぁ。
s3からtemplateを指定。
template urlはhttps://s3-ap-northeast-1.amazonaws.com/ijin/aws/lambda/check_lambda_capacity/check_lambda_capacity.template
Parameterとしては以下が指定可能
Stackを作成すると、諸々のリソースが数分で出来上がり。
本当は以上で終了!にしたいところですが、LambdaのScheduled Eventsの設定はAWSコンソールからのみしか出来ないという情けない残念な状態(2016/1/14
現在)なので、ここからポチポチ設定作業。。(API重視の開発姿勢はどこ行ったんだろう)
(*) 2016/1/26
追記:この記事の翌日に発表された CloudWatch Events
の scheduling
機能 によって出来るようになりました。なんというタイミング。
最小頻度が5分毎
これで、グラフが取れて閾値を超えたらアラートが飛ぶようになる
出来上がったCloudFormation templateコードはこちら。AWS::Lambda::Function
がlambdaのresource担当だけど、templateにfunctionをインラインで埋め込めるのは現時点ではnodejs
のみなので仕方なくzipしたpythonコードをs3にアップして参照するようにしてる。
元気があれば、そのうちnode版も書こうかな。。
GitHubのリポジトリはこちらから。
]]>インドネシアのバリ島は日本からやや西にほぼ南下しただけなので、時差は1時間程度。
山岳エリアにあるウブドという地域。
そこにあるMonkey Forestというジャングルの近く。猿がそこら中に。
HUB in UBUDなのでHubudという名称。
$60〜の月額プランを支払う事によって、館内で使える時間数が決まる。平日は24時間アクセス可能で、土日は22時ぐらいに閉店。(2015年12月現在)
今回は$60(+$3の処理手数料)を事前でPaypalで払って、25時間プランに加入。
ちなみに、bitcoinでも支払い可能。
中にはbitcoin自販機も!
館内には24時間いつでも入れるので時間のトラッキングはどうなってるかというと、恐らく登録時にノートのwifiを設定したので、そのmac addressで識別していると推定。
リラックスした感じでアットホームな雰囲気。
フリーデスクで館内でも中庭でも作業可能。
お気に入りの作業場所。但し、夜になると蚊が出てくるので蚊よけスプレー必須。
2階にはゆったりソファも。
free coffee!
宿のwifiや現地のキャリアで買えるSIMカードによる通信品質はそれほど良くなく、時間と場所によってはパケットロスが大量に発生。
しかし、Hubudに引いている回線は帯域が太く、レイテンシーもほとんど感じられずに超快適!ストレスなく通信ができるので日本にいるのとさほど変わらないぐらいの感触。
たまには作業場所を替えて仕事して見るのも一興です。異なる環境に身を置くことによって、いつもとは違った感じの集中力が発揮でき、短時間で没頭してproductivityが向上する場面がいくつかありました。(昼間の熱い時間はプールに入って涼んで、夕方から夜まで作業するスタイルが結構効率的でした)また、いろんな国やバックグラウンドの人がいるので会話してみると良い刺激にもなるので是非一度体験してみてはいかがでしょうか。
]]>AWS Lambdaで開発してるとちょこちょこ実行ログを見たりします。cliであれば、@sgwr_dtsさんのlambchopがtail
的に使えて素敵なんだけど、後で見返したり、検索したりするので、最近ではログをSlackに通知するようにしているのでその紹介を。
イメージはこんな感じ。
ログはCloudWatch logsに溜まるのでsubscriptionさえ出来れば、別にソースはLambdaじゃなくても良いんですけどね。
CloudWatch logsのイベントをparseして、日付の色付けやタイムゾーン変換等ちょっこっと加工してメッセージと共に指定の#channel
に飛ばすようにし、別のSlack通知用lambda functionをinvokeしているだけですね。
(Slack用のlambdaは以前のエントリを参照)
何故Slackの部分を別functionにしてるかというと、最小単位の機能の切り出しによるportabilityとcross-account間のinvokeが可能となるreusabilityからです。
1 2 3 4 |
|
1 2 3 4 |
|
これでlambda functionが実行されると、Slackにログが通知されます。
うん、見やすい。
これでログが飛ぶようになったのは良いですが、Lambdaが実行されてからSlackへの通知まで10数秒とやや長めの時間がかかってしまうのが現在の難点です。(Immediate Feedbackはないものの履歴や検索用途には十分だけど)
調べてみるとLambdaからCloudWatch logsへの書き出しが一番時間がかかっているのが判明。Logsへ書き出されたら、そこからの処理時間は1〜2秒とちょっと前に発表されたCloudWatch logsのnear realtime processingの通りなので、早くLambda -> CloudWatch logs
も同じような処理時間を実現して欲しいものです。
まあ、別にCloudWatch logsにさえ入れば早いので、lambda logに限らずいろいろ応用できそうですが。
では、Happy Lambda Life!
参考
]]>eb ssh
コマンドを使えば割りと簡単に接続できますが、アクセスキーの設定が必要で、開発者が多い場合にそれを発行してばら撒いて管理するのはかなり面倒です(IAM user/roleの割当にしても)。特に極稀にしか接続する必要がない場合。
そこで、API GatewayとLambdaでinstanceのpublic ipを返却するエンドポイントを作り、SSH configを設定すれば誰でもアクセスできるようにしてみました。
NewestInstance
やってる事は単純で自動的に付与されるelasticbeanstalk:environment-name
タグのついたinstanceのipを(パラメータに応じて)返却するだけ。複数ある場合は、起動した順で。
せっかくなので新しくサポートされたPythonで記述。
当然、LambdaのIAM roleでec2:Describe*
のAction許可も必要。
API Gatewayのresourceをコンソールでポチポチ作るのがイヤだったのでAPIの状態をSwaggerで定義してみた。awscliは生REST APIが辛い。
編集しながらドキュメントも見れるonline editorが結構便利。
Swagger上でYAMLで作成した定義書はjsonとしてexportし、aws-apigateway-importerでAPIのresourceやmethodやらを生成する。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
これでAPI Gateway上に階層が出来上がり。
後は各GET method
でLambdaへの関連付けをし、Integration Request
とIntegration Response
のmapping template
でパラメータやレスポンスを設定。(多分、この手順もswaggerで定義できるとは思うけど)
参考:
Deployすれば、以下のAPIでipが取得可能。
/$API_ENDPOINT/prod/eb/$EB_ENV_NAME/ip/[n]
instance ip一覧
1 2 3 |
|
特定のinstance ip
1 2 |
|
ipの部分だけ、PATHじゃなくquery paramterにした方がAPI Gatewayの設定がシンプルだったけど、少しでもRESTfulにしたかったもので。(まあ、そもそもjson返してないけど)
さて、ここからがキモです。
~/.ssh/config
1 2 3 4 |
|
上記の設定でssh $EB_ENV_NAME[n]
で指定したサーバに接続できるようになります。
仕組みとしては、ホスト名をparseしAPI Gatewayに適切なリクエストを行い、返却されるpublic ipにローカル端末自身を踏み台としてsshするProxyCommand
の設定です。
例えば、2番目(に起動した)のサーバに接続する場合は
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
1番目の場合は明示的に指定する必要はありません。
1
|
|
また、Auto Scalingでinstanceが増減せずに1台のみの場合はもっとシンプルに記述できます。
1
|
|
簡単!
でも、よくよく考えたら普通のAuto Scalingの場合でも利用できる事に気付きました。
Unicornを貸し出すサービスを展開する仮想のスタートアップ企業にDevOpsチームとして最近入社したという設定。前任者が退職しており、資料が少ない中でサービスオープンに立ち会いつつ、様々な困難に直面するというフルデイ・イベント。 今までのGame Dayと違って面白いのはパフォーマンス・チューニングをしつつも、コストも意識しながらチーム間でスコアを競争するところ。アプリは触れないので、ISUCONよりは昔やったチューニンガソンに近い感じ。
スコアは累積の損益。アーキテクチャによっては利益が出たり損失が出たりする。例えば、多くのリクエストが処理できると利益は増すが、AWSのリソースが多いと費用が掛かって損失になりうる。 当然最初は各チームは赤字から始まり、時間とともに積算した利益によって黒転して行く様が目新しかった。
結果、48チーム中で6位。(上位2チームはチートで失格となったので実質は4位)
ちなみに最速レスポンスタイムはうちのチームが叩きだした。
詳細は今度日本で開催されるかも知れないので控えておくが、非常に楽しめたので次回は運営側に回って手伝おうかと思います!
Andy Jessy副社長による発表。今年のテーマは「自由」
Oracleからの自由、解放!
実在した、ある企業のクラウド移行案件。RFP的なモノがあり、アーキテクチャをチーム内で議論し、最後にそれぞれ各チームが発表していく流れ。 かつてjawsugで主催を手伝ったワールドカフェ形式とほぼ同じだったので、チームメンバーを先導してCacooでさくさく構成図を起こしていく。 他のチームが模造紙にラフスケッチで発表する中、我らは綺麗に正本して、プロジェクターで登壇しながら発表。
最後に実際にどう移行したかというAWSチームからの回答。まず、移行フェーズを段階的に分け、最初はシステムをほぼそのままクラウド上に乗せた後に部分的に最適化してコンポーネントを置き換えて行ったという話。最後にLambdaになっていた部分があったのが興味深かった。
早く新サービスに対応したAWS Simple Iconsのアップデートが待たれるところ。
今回提案した内容。
Zombie Apocalypseが起こって、人類存亡の危機!途中まで実装されたチャットルームの機能を拡張・実装して危機を救え!というシナリオの元、LambdaとAPI Gatewayとjavascript sdkで実装されたサーバーレスアーキテクチャのワークショップ。
機能拡張の為に実装が必要なので、設計しながらチーム内で作業分担し、コードをせっせと書いていく。 ゾンビ出現のアラート通知、ヒートマップ描画、アンデッドカウンター、緊急食料倉庫の位置情報配信等、面白い機能要求が盛り沢山。
ささっとSlack部屋を作り、githubでコードを共有しながらのチームワーク作業。多分、うちらのチームが一番多く実装できた感触。
このワークショップはかなりの人気で、開始30分前にすでに長蛇の列が。 運良くぎりぎり最後の参加者として入れたけど、皆どれだけゾンビが好きなんだ。。
Wernerl Vogels CTOの発表。
前日にAndyが7つの自由を語って、当日はWernerが7つの法則を語る。
Amazon Echoを使った、Alexaのプログラミングワークショップ。音声によって、Echo経由でLambdaイベントを呼び出し、Alexaサービスと連携するカスタマイズしたスキルセットを実装して行く。
例えば、Alexaに好きな色を覚えさせて、後ほど聞くと答えてくれる機能とか。全てボイスコントロール。吉田さんの英語でも通じたので、かなり優秀。
新品のEchoを開封して使ったので、最後に貰える物かとささやかに期待したものの、$15のAWSクーポン配布のみ。さすがケチFrugalなAmazonさん。
EDMの若きプリンスDJ、Zeddをシークレットゲストとして呼んでのアフター。
もう完全にWernerのパーティー。
Zeldaのremixが良かった。
結局セッションは一つも出なかったです。まあ、ビデオやスライドは公開されるので内容自体は後で把握可能なので別にいいかな。授業を聞きに来た分けでもないし。 それよりも、現地に来ているエンジニアと交流したり、実装まで含んだハンズオンのワークショップをやった方が楽しいし、糧となる。後はトレンドを肌感覚として体感するには良い場所なので行った事ない人には是非オススメしておきたい。
]]>