(レポート)[ServerlessConf London] キーノート「Serverless is More」 #serverlessconf

はじめに

本レポートは2016年10月27日(木)〜28日(金)に開催されたServerlessConf Londonのキーノート"Serverless is More(more or less)"のレポートです。

本セッションのスピーカーはDevOpsの名付け親でもあるPatrick Deboisさんです。

AWSに依存したテーマというではありませんが、AWSクラウドの技術を例にトークは進みました。

発表資料

動画

 

スライド

見当たらず

バックグラウンド

• 2009年に初めてDevOpsを提唱
• この業界に20年いる
• メディア系のスタートアップにつとめていた

メディア系サービスの特徴

• テレビでサイトが紹介されると、リクエストが殺到する。
• スケーラビリティが求められる
• 闇雲にスケーラビリティを追求すればよいわけではなく、コストとのバランスも求められる
• アクセスの規模を予測するが、予測を上回る規模のアクセスがあったときは、1分以内に、実際のアクセスにもたえるようにスケールしないといけない
• サーバーレスが向く
• 1時間番組のウェブサイトの場合、システムの不具合も、その放送期間中に修正しないといけない。

サーバーレスについて

• サーバーレスは最新のテクノロジー
• ただし、サーバーレスを支える基盤技術は別に最新というわけではない
• コンテナー
• スケジューラー
• プロキシー

サーバーレス化してサービスのレスポンスは早くなるのか？

• コンテナー化したら、同じ機能を持ったサーバーを簡単にデプロイできるようになる
• サーバレス化が必ずしも高速化につながるわけではない。
• コンテナの初回起動は時間がかかる。
• アクセスが頻繁でないサービスで、ユーザーのリクエスト時にコンテナの起動も起動も発生すると、レスポンス時間が伸びる。
• マイクロサービス化すると、局所的な処理時間が短くなっても、サービス間で通信が増え、エンドユーザー視点ではトータルのレイテンシが増えることもある。

サーバーレスの信頼性

• マイクロサービス化すれば、アプリの責任範囲が狭まり、信頼性が増す
• 依存しているマネージド・サービスがどのように動作しているのか理解して使わないと、信頼性は増えない
• AWS Lambda であれば、コンテナーの再利用など。

セキュリティ

• サーバーレス以前であれば、プロキシーサーバーを間に立てるなどして、アクセスを細かく制御できた
• マネージドでは、WAFなどのソリューションはあるけれども、やれることには限りがある
• クレデンシャルの管理や通信の制限などで、サーバーレスサービスの改善の余地は大きい
• 独自のクオータ管理(ユーザーごとの呼び出し回数制限など)を組み込むことも難しい。

サーバーレスで安くなる?

• 部分的にはね
• サーバーレス系サービスは従量課金なので、予算見積もりが難しい
• サーバー管理者のコストは浮く。人件費はリソースで一番お金がかかる。
• 一方で、サーバーレスアーキテクチャーを理解し、マネージド・サービスの仕様変更に追従するエンジニアのコストが発生する。外部サービスの変更は自分たちではコントロールできない。
• 結局、サービス全体としては、そんなに安くなるわけではないのでは?

よりよいサービスへ

• サーバーレス系サービスは
• ログ
• 監視
• 通知
• 機能が今一歩なものが多い

機能の追加

• サーバーレスサービスのテスタビリティはまだ成熟していない
• 単体テスト・結合テスト
• コードの修正はすぐに終わる
• 修正したコードのテストが短くなるわけではない。テストには長い時間がかかり、改修工数全体の大部分はこのテスト工数
• 結合箇所がボロボロとうごかなくなることもよく起こる

サーバーレス化のメリットとは?

• 流行っているからといった理由でサーバーレス化してもしかたながない
• サーバーレスにすることでどういうメリットがあるのか、ビジネス視点で考えた上で採用すること

まとめ

ソフトウェアエンジニア視点で自分が開発する狭い範囲だけを考慮するのではなく、運用後のコストや隣のシステムとの連携も考慮して、サーバーレス化を評価しましょう。