[Serverlessconf Tokyo 2018] 基調講演: AWSにおけるサーバーレスの歴史と開発をするなら

今年のServerless Conf最初のセッション。AWSにおけるサーバーレスの歴史と今開発するなら何が使えるのか、AWSの西谷さんの基調講演です。
2018.10.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、サーバーレス開発部の夏目です。

先日 Serverlessconf Tokyo 2018に参加したので、そのレポートです。

AWSの西谷さんの基調講演 "サーバーレスのこれまでとこれから"の内容をお届けします。

価値を届けるためにDeveloperはアプリケーションを開発する

サーバーレスの歴史の前にそもそも何で開発するんだっけ? という話。

「何がしかのサービスを作って価値を届ける」ために開発をしている

コードを書くのが好きな人もいるんだけども、ビジネスの一環で開発しているという前提で話をしていた。

じゃあその価値とは何かというと、「価値 = (自社のサービスの)差別化」。
(他では代替できない、自分たちのサービスでしかないと利用できないものこそが価値なんだって意味だと自分は思った)

価値を生み出すビジネスロジックに人も集中したい。
だけど、なかなかそうはいかない。

Undifferentiated Heavy Lifting

"Undifferentiated Heavy Lifting"(価値をとどけない無駄な作業)というものがある。

  • サーバー構築 (セットアップやインストール、設定)
  • キャパシティモニタリングとそれを踏まえてのスケーラビング
  • 耐障害性のために複数台構成
  • インフラ以外でも、認証認可だったりAPIのスロットリングだったり

などなど、必要がないわけではないんだけどそれそのものがビジネスになっていなければ付加価値にはなりにくいものがある。

それらに時間がとられてしまうために、"ビジネスロジックに集中できない"。

サーバーレスの誕生と歴史

そんな中、2014年のre:InventでAWS Lambdaが発表された。
最初はプレビューにも関わらず、反響が大きかった。

日本でも反響が大きくて、Advent Calenderが作られた。 発表直後で申請がいるプレビューだから、書いてる人の多くはまだ使えない人たちが書いてくれた。

AWS Lambda Advent Calendar 2014

Lambdaから始まったServerlessの成長をまとめると以下のようになる。

2015年はAWSのサーバーレスにおいて重要な年でAPI GatewayがGAされた。
2016年にはVPCをサポートし、今年はGolangのサポートやPrivate APIなどがリリースされた。

LambdaはMVP(Minimum Viable Product)ではじめて、早い段階から使っているユーザーからのFeedbackを受けながら進化してきた。
その結果非常に利用が広がっていて、特にここ2年で増えている(グラフはLambdaとAPI Gatewayの売上)。

Web系/ゲーム系の利用が多かったけど、最近の傾向としてエンプラとかトラディショナルな企業からサーバーレスの相談を受けている。 つまりは、あらゆるワークロード/業種/業態のユーザーに使ってもらっている。

サーバーレスの効果

サーバーレスにして何が嬉しいか。

  • サーバー管理が不要
    • 開発者は関数を実装するだけでいい
  • 柔軟なスケーリング
    • 非常に伸縮性が高い
    • リクエストが増えたからサーバーを増やすとかする必要がない
  • 組み込まれた高可用性
    • 自動で行われる
    • 冗長化とか耐障害性とかを他の手段でやろうとすると、実装量とか増えてしまう
  • アイドル時のリソース確保不要
    • 実際にコードが動いた時間や回数で課金される
    • つまり、リクエストが飛んできていない時間だったり、処理が動いていない時間は費用が発生しない

これらによって、以下の効果を得られる。

  • 開発効率がよくなる
  • アプリケーション開発のサイクルが早くなる
  • より差別化につながるような開発にフォーカスしやすい

つまるところ、付加価値を産まない作業から大部分開放される。

サーバーレスの開発

Lambdaで連携できるサービス郡や開発ツール郡。
多くのイベントソースに対応し、いろんなところでLambdaが動く。

サーバーレスで使用できる開発ツールもいろいろと出てきてる。

  • Serverless Application Model (SAM)はCloudFormationの拡張なのでCloudFormationと同様に管理/デプロイができる。
  • SAM CLIではコンテナを使えばLambdaでは難しかったローカルテストが可能になる。
  • Amplifyはフロントエンド、モバイル用のオープンソースなJavascript ライブラリ。

アプリケーションの開発のパイプラインをざっくり見てみると以下のようになる。

  • Source
    • GitHub
    • Code Commit
  • Build
    • CodePipeline/CodeBuildを使用して自動的に依存関係の解消やビルドを行う
  • Beta (Staging)
    • SAM
      • 完成したアプリケーションをステージングにデプロイ
  • Test
    • テストについてはAWSは提供できていない
    • 3rd Partyのものを使うしかない
  • Prod
    • SAM
      • CloudFormationの拡張なので本番環境にもBetaと同様にデプロイすることができる

事例

東京海上日動火災保険

ログ処理と可視化の基盤をサーバーレスで開発。
4人くらいで開発をしたらしい。

Sansan

Eightのリアルタイムリコメンデーションの機能。
リアルタイム性を高めることで、つながりの承認率を向上させた。 2ヶ月くらいで実装。

If Amazon.com were starting today, it would go serverless.

セッションの最後に紹介していた言葉。
AWSのCEO Andy Jassyが言ったらしく、サーバーレスのポテンシャルを非常に表現している。

まとめ

Serverless Conf Tokyo 2018の基調講演の内容でした。
自分が把握している以上に、イベントソースが多くてびっくりしました。

Amplifyが面白そうなので使ってみようと思います。