Serverlessconf Tokyo 2017 に行ってきました
11/03(金) に開催された Serverlessconf Tokyo 2017 に行ってきました。
参加のモチベーションとしては現在 AWS Batch を活用してバッチシステムを作ろうとしているのと、AWS Lmabda を使って AWS サービス同士をのり付けしているうちにこの分野に興味が湧いてきたところでちょうどいいところに Serverlessconf の開催を知ったため最新情報を仕入れようと思って参加しました。 それからよくある文脈としては「サーバーの管理をしなくていいぜ、やったー」みたいに語られることが多い気がしているので果たして本当にそうか？という疑問を解消したかったのもあります。
イベントそのものの話
セッションは2トラックあってどちらも混みすぎることなく基本的に着席して聞けたのでよかったです。 スポンサーブースもアンケートに答えるとTシャツもらえたりして豪華だった気がします。 著名な方が普通にブースにいて気軽に話せるのはよく考えるととてもすごいことなのでは...と思ったりました。
あとお昼に出たお弁当が美味しかった。
以下、聞いてきたセッションの簡単な感想です。
"サーバーレス"を語るときに僕が語ること
良い話でした。Serverless はサーバー管理から解放されてイイゾ〜という話がありがち、からのちょっとまてよ、議論すべきはそこか？という話。
アーキテクチャを変えずにサーバー管理からの解放を目的として導入してしまうと謎のワークアラウンドを重ねて結局 Serverless の利点を失ってしまう。
本当にフォーカスすべきは自分たちのシステムを動かすコードなわけで、自分たちのコードを最大限に活かせるマネージドサービスを使ったアーキテクチャはどうやって実現すればいいのか、を考えましょう、議論しましょう、という話は共感できました。
サーバレスアーキテクチャによる時系列データベースの構築と監視
Mackerel の時系列データベースについて。
AWS のマネージドサービスを活用して作った時系列データベースを「diamond」と名付けていてそれを構成する各マネージドサービスをどうやって監視しているのか、という話でした。
知見しかないのでぜひスライドを見てみてください。
各マネージドサービス単体で監視するだけでなく、系全体の可用性を監視する。そのために平時状態を知り、定義する。それを監視するために必要であれば監視そのものを作る。
Step FunctionsとAWS Batchでオーケストレートするイベントドリブンな機械学習基盤
ちょうど AWS Batch でバッチシステムを構築しているという事もあってタイムリーなセッションでした。
監視まわりをどうするか、が課題になっているのですが「起動するはずのジョブがそもそも起動しなかった」の監視はかなり難しく、ここでは Datadog を使ってジョブが一定時間起動していないと通知ということをしているそうです。
その他 Lambda の二重起動にはべき等なジョブにし、DynamoDB にジョブのステートを保存してすでに起動済みだったら実行しない、などの制御もしていました。
Open source application and Ecosystem on Serverless Framework
Serverless Framework はクラウドコンポーネントを抽象化し、sls コマンドで必要なコンポーネントごとデプロイしてくれるのでオープンソースソフトウェアのミドルウェア化として活用されていくのではないか、という話。(この解釈で合ってるかちょっと自信ないです)
Heroku の deploy ボタンのようにボタン1個押せば裏で sls コマンドが走ってユーザーは詳細を知る事なく、そのオープンソースソフトウェアを使えると。
まさに目から鱗で、こういう考え方もできるのか、と新しい視点が持てました。
Biz Serverless お客様のサービスを支えるサーバレスアーキテクチャーと開発としてのビジネスの課題
Serverlessconf Tokyo 2017 Biz serverless お客様のビジネスを支える サーバーレスアーキテクチャーと開発としてのビジネスの課題 from Hiroyuki Hiki
MSP としてサーバレスアーキテクチャを構築する際にどのような課題があるか、という話。
- なぜサーバレスアーキテクチャを使うか
- EC2 環境は汚れないけど監視のポイントは増える
- シンプルなシステムを複雑化してるだけなのでは
- ほんとうに必要な部分だけ Lambda を使う
- 他のサービスが死んでてもあとから自動復旧するようにキューイングしてる
- DDoS は WAF を使ってガードする
- 開発コストとランニングコストの兼ね合い
- 障害発生時にあとでリカバリーする方法を考えておく(設計時に考える)
- 性能面は期待しない作りでカバー
- 同期で処理するべきか、遅延処理でいいのか考える
- イベントドリブンになるので構成が複雑
- 自動復旧などを最初から考えるから実装工数が増える
- 開発コストが上がりやすいのでコンペに負けやすい
今年の JAWS DAYS でもお話を聞きましたが今回は MSB動画イズム444 以外の事例も紹介されていました。 課題を解決するためにサーバレスアーキテクチャを選んでいるとともに各システムの特徴も話されています。
基本的に接続先のサービスを信用しないでもし動かなくてもなんらかの手段でリカバリーできるようにしておく、監視しておく、というのはサーバレスアーキテクチャを使う際は必須要件ですね。(といってもサーバレスに限った話でもないですね)
全体的に
本当にいろんな話が聞けて満足です。で、実際どうだったかーというところですが、
Serverless は新しい「考え方」、ということですね。
開発者の生産性を上げるひとつの方法。インフラを抽象化してアプリケーションから切り離すもの。そのためにアプリケーションの作り方を変えていく必要があって、サーバからの解放はその結果でしかない、という感じでしょうか。
といってもシステムをすべて Serverless で構築するのはなかなか難易度が高いように感じています。(構成の複雑化や監視のポイントの多さなど)
今後各クラウドベンダーのエコシステムが発展してそのあたりのハードルがどうやって下がっていくのか注目していきたいです。
現在だと Serverless の特性である、並列処理(負荷が動的で読めない、等)が活きるような箇所に導入したり、単機能のシステムに採用していくのが良さそうです。
Serverless でどんな課題が解決できるのか見極めた上で採用できれば強力なアーキテクチャだと思うのでハマる要件があれば積極的に考えていきたいです。
