この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
【パネルディスカッション】サーバーレスの波はホンモノか？ 最前線の開発者に聞くコードでサービスの全てを提供する方法
6/1 (水) ~ 6/3 (金) に開催された AWS Summit Tokyo 2016 の Develoepr Confrence のセッション「【パネルディスカッション】サーバーレスの波はホンモノか？ 最前線の開発者に聞くコードでサービスの全てを提供する方法」を聴講しました。本記事はそのレポートです。
スケーラブルなアプリケーションやマイクロサービスを構築する上で、インフラの管理から「解放」されるサーバーレスアーキテチャーが注目されています。このサーバーレスアーキテクチャーが、どのくらいのインパクトを持つものなのか、実際にアプリケーションやサービス開発の最前線で活躍されている方をお招きし、その実態や期待値をお伺いするとともに、今後の進展についても議論します。
モデレータは西谷 圭介氏(アマゾン ウェブ サービス ジャパン株式会社 技術本部 レディネスソリューション部 ソリューションアーキテクト)、パネリストは木田 茂穂氏(株式会社リクルートジョブズ デジタルマーケティング室 マーケティング部 データマネジメントグループ グループマネジャー)、鈴木 健太(株式会社 fluct fluct開発本部 エンジニア)です。
セッション
記念撮影
セッション開始早々、記念撮影が始まりました。
西谷さん「実際にサーバーレスでプロダクション環境を構築されていますが、実際に作ってみてどうだったのか、苦労した点をお聞かせいただきたいと思ってます。本題に入る前ですが、前のセッションで自撮りをしたと聞きましたが、どうですか？」
鈴木さん＆木田さん「撮りたいです！」
西谷さん「じゃあ撮りましょう！」
＼パシャッ／
システム概要
パネリストのお二方が担当されているシステムの概要をご説明いただきました。
鈴木さんは fluct の広告配信ではなく、ドキュメントをクロールして分類するシステムを開発しています。本文抽出機に Lambda を使用。前段でシードを集計、クローラから Kinesis Streamで流して Java 8 で動作する Lambda が処理。
木田さんはタウンワークのアプリから取れる回遊情報を計算し、計算結果を画面にリアルタイムに反映する仕組みを作っています。回遊情報が送られてくるの APIGateway から Kinesis に流し、EC2 で計算して DynamoDB に保存します。また、Lambda を定期的にキックしてログを S3 に保存。一部で ECS を活用。
AWS Lambda を採用したきっかけ
鈴木さん
- 本抽出処理を Java 8 で作りたかった
- Java は環境を rpm で入れるのは単純かと思われがちですが、監視やミドルウェアの導入を考えると結構大変(Lambda だと不要になる)
- Apache Lucene の Java 版は使い勝手が良いから
- 言語の採用は基本的には適材適所
木田さん
- 作るものがサーバーレスでトライアンドエラーを繰り返すのに最適だった
チーム編成
インフラチームとアプリチームは分かれているか？という質問です。
鈴木さん
- サービスごとに違う
- 分かれているというより、専任が居る
- 鈴木さんは普段アプリ側
- デプロイはアプリ側の担当者が行い、ミドルウェアはインフラ
木田さん
- メインのタウンワークはインフラとアプリで分けれている
- 検索と結果に特化している機能の開発チームについてはちょっと違う
- アプリ側の開発者で構成
- インフラエンジニアは調達できたかどうかというと頑張れたかもしれないが、統計の手法だとかを説明するのはどう頑張っても回らない
- 監視やミドルはインフラエンジニアが担当
なお、インフラエンジニアと仕事がし辛いということではないことを言及されていました。メリットデメリットがある中で、取捨選択をしたということです。
コスト
開発したり運用したりする中で、サーバーレスのメリットや課題、考慮点などを掘り下げていきます。よくサーバーレスで話題に上がるのがコスト感だそうです。
鈴木さん
- Kinesis Stream の受け口は Lambda 使うか KCL 作るかの2択になるが、Lambda を採用した
- 実装に時間をかけたわけではない
- Lambda は何をさせたいか決めてから作り始めるため、仕事が明確
- 書き方が分かれば実装に時間はかからない
- 金銭コストより人が動くコストの削減を優先した
- このブランチに対する Lambda で作るので、試行しやすく時間がすごい短縮された
- 結局サーバー代よりもエンジニアの稼働費の方が高い。それを軽減してくれるツールがあったらそっちの方が良い
木田さん
- 同じことを言いそう
- 金銭面もあるが、自分自身で試すという実装スピードのコスト間で使っている
それから、Lambda は新しものなので、西谷さんはお客様と話をしている中で Lamdba の挙動などで学ぶのに時間が掛かるという話がよく挙がるそうです。学習コストがかかる中で、どのようなところにメリットを感じて使用しているのかという質問です。
鈴木さん
- 新しい仕組みを使うのは仕方ないと思っている
- でもそこまで学習する時間はかからない。
- 時間かかっていたところでいうと、ビルドしたものをどう置いてデプロイするか
- Node.js だとインタラクティブで書ける
- Java だとパッケージングしないといけない
木田さん
- トライアンドエラー
- 試してすぐ学習してを繰り返し、結果すぐに学習できる
学習
学習コストは Pay しちゃうという話がありました。学習するには、自分たちが手を動かした方が良いという話に。
鈴木さん
- 自分が動かすのが一番早い
- Node.js でどうやってデータが流れてくるかまず確認した。流れてくるのが分かれば仕事は変わらない
- 止まるってのがポイント。Kinesis Stream を受けている場合解消するまで止まってしまう。これは挙動を知ってないとまずい。
- 公式ドキュメントを参考に学習。まずはウォークスルーをやってみる
- 他のメンバーには、イベントというものがあって、…といったように説明してキャッチアップさせる
木田さん
- 最初に試すのに時間がかからないよう、まずは試す
- そのプロセスをどうするのかが重要
- 検証パターンがある。まずは試してどういうのが流れて、どういうのが止まるか。検証というよりは実験に近い
- 現場のエンジニアから上がってくることが多い。使ってみたらよかった、という話は後から来ることが多い
- 事後報告みたいな感じ。僕が怒られればいい(笑)
デプロイ
鈴木さん
- S3 に置いている
- アップロード済みのものを本番に手動(コマンド)で反映
- GitHub でコードを管理
- マスターブランチにマージするとで Travis CI が走る
- Travis CI の中で S3 に配置
- あとはワンコマンドで反映可能な状態になる
- Lambda だからどうということはなく、やり方分かれば API でOK
- Lambda Function は基本1個
木田さん
- 全てのコンポーネントのデプロイを自動化
- Java はコンパイルが必要ですが Python は Zip 化するだけで良い
- かなり多いコンポーネントがあるが、それをまとめて Zip 化する
- Lambda だから難しいはなかった
- Lambda Function の数は1個や2個ではなく、沢山ある
テスト
鈴木さん
- Kinesis Stream から来るというところは変わらない
- どういうデータが来るとどういう処理を行うか、という単体テストを実施
- ローカルでも、CI でも実行可能
- Integration Test も行っている
木田さん
- パラメータを変えると Dev や Prd になるように実装
- 非常にタイミングがシビア。テスト、デバッグは非常に苦労している
- ベストプラクティスに辿り着いていない
- 動かしてテストというのが多い (ローカルで実行可能な単体テストもある)
- どこ何でテストするのか切り分ける
逆に鈴木さんから西谷さんに「Lambda は CloudFormation に含めていないのだが、全て含めてテストするという方法もあるのか？」という質問がありました。
AWS のサービスは全て API があるので、Kinesis Stream のテストデータを流して、動作を確認するといった流れは行え、チェックが終わったら全てのリソースを消すという方法が取れるとのことでした。
デバッグ
鈴木さん
- CloudWatch Logs を愚直に見る
- Kinesis Stream を Tail するツールを書いた (suzuken/kinesis-tail)
- CloudWatch Logs は awslogs というツールを使用 -> 使い方はこちら
- ツールを使うと愚直に見るのとあまり変わりはないが、期間指定などが柔軟
木田さん
- CloudWatch Logs を愚直に見る
感想
Lambda におけるコスト、デプロイ、テスト、監視などの考え方について、実際に行なわれている方法をご紹介いただく中で学ぶことができました。
「Lambda だからと言って特別なことはない」という点が重要です。従来のサーバーを立ててアプリケーションを動かすのと比較すると、やりたいことは変わらないので、やらなければいけないことも自ずと一緒になってくるという感じでしょうか。
あとは、木田さんがおっしゃっていた「まずは試す」というところ、ある意味 AWS のサービスの基本かも知れませんね。どんどん新しいサービスが出るので、どんどん試していきましょう！
14
