「ServerlessDays Tokyo 2019」に参加してきました

勉強会メモ
  • ServerlessDays Tokyo 2019に参加してきました。

tokyo.serverlessdays.io

  • 事例紹介のセッションではかなり踏み込んだ設計の話をしてくれることが多く参考になることが多かったです！
タイトル 発表者
10x Serverless Product Development for a Startup with Microsoft Azure Yutaka Tachibana(EBILAB)
Keynote Keisuke Nishitani (AWS)
Keynote: Infinite Scaling, Finite Failures: Serverless Resiliency Patterns and Lessons Learned Katy Shimizu (Microsoft)
グローバル展開のコネクティッドカーを支える大規模サーバーレスシステム事例 Yuya Urayama (TOYOTA), Takanori Suzuki (Acroquest Technology) and Eiichiro Uchiumi (AWS)
All You Need Is JavaScript Jensen Hussey / Cloudflare
Zero Scale Abstraction in Knative Serving Tsubasa Nagasawa (CyberAgent)
空調設備向けIoTシステムにおけるクラウドランニングコスト 野原 健太 / ダイキン工業株式会社
ISPがサーバレスに手を出した 伊藤良哉 & 松田丈司 (NTTコミュニケーションズ)
AWS Lake Formation で実現、マイクロサービスのサーバーレスな分散トレーシング 江藤武司 & 岩井良和 (Sony Corporation)
Don’t think Serverless Security, think Application Security Ido Neeman (Nuweba)
Azure でサーバーレス、 Infrastructure as Code どうしてますか？ Kazumi Ohira
The hidden cost and technical debt of running huge Serverless service on production James Nguyen / MaaS Global

10x Serverless Product Development for a Startup with Microsoft Azure

  • Yutaka Tachibana(EBILAB)

スタートアップ × Microsoft Azure

EBILAB

開発しているもの

  • BIツール
    • どれくらいの人が来客するか予測
  • 画像解析
    • 入店客の人数や属性をカウント
    • 通行人数もカウント

Microsoft Azureのサーバーレスコンポーネント

  • Functionse
    • DBにデータを入れるところまで
    • LogicApp
  • PwoerBI
    • エクセルのデータをもとに表示することもできる
    • DBとかAPIから取得したJSON
  • WebApp
    • Nuxt
    • Laravelで認証
    • PwoerBIで作ったレポートをiframeで呼び出し

サーバーレスで作ったメリット

  • 開発運用コストが従来のモノリシックより少ない
  • 責務分離が自然と行われる
  • 将来的にスケールしても問題ないと楽観視できる
  • 不要になったパーツを捨てやすい
  • 分業協業しやすい

Keynote

  • Keisuke Nishitani (AWS)

Event Driven

  • LambdaはサーバーレスよりもEvent Drivenをキーワードにしたサービスだった
  • 状態の変化をイベントとして捉えて処理を実行する
  • Event Driven出ない場合処理が増えると呼び出し元にも手を入れないといけない
  • Event Drivenならサブスクライブを追加するだけ

Lambda

  • 2014年に発表
  • 当初はEvent Drivenや関数実行がキーワードだった
  • 2015年にAPI Gatewayが出てきてサーバーレスという言われ方をし始めた

Lambdaのネットワーキング

  • Lambdaの実行環境ははサービスチームのVPCで動いている
  • ユーザのVPCにElastic network interfaceを通じて接続できる
  • スケールするとサブネット内のIPアドレスを使っていく
  • ENIの作成に10~30秒時間がかかる

AWS Hyperplane

  • internal network load balancing service
  • 内部的に動いてるサービス
  • ユーザは使えない

VPC環境の改善

  • AWS HyperplaneをベースにしたVPC to VPC NATを使う
    • コールドスタートレイテンシの改善
    • ネットワークインターフェースの共有
    • スケーリング
  • LambdaからRDSへの接続
    • VPCのコールドスタート問題が解決する

モダンアプリケーション

  • 特徴
  • アプリケーション実行環境
    • EC2
    • ECS/EKS/Fargate
    • Lambda
  • マイクロサービス
    • サービスごとにデータを永続化するので疎結合
  • APIはマイクロサービスの玄関
  • メッセージングを活用してコードからステートを取り除く
  • クラウドネイティブなアーキテクチャ

Keynote: Infinite Scaling, Finite Failures: Serverless Resiliency Patterns and Lessons Learned

サーバーレス

  • サーバの抽象化
  • イベント駆動型
  • 従量制課金

すべての依存は障害になりうる

  • レースコンディション
  • ネットワーク障害
  • レート制限
  • ハードウェア障害
  • => 再試行のデザインパターン

グローバル展開のコネクティッドカーを支える大規模サーバーレスシステム事例

  • Yuya Urayama (TOYOTA)
  • Takanori Suzuki (Acroquest Technology)
  • Eiichiro Uchiumi (AWS)

はじめての大規模アジャイル

トヨタのコネクティッドサービス

  • 車載デバイスがネットワークに繋がる
  • 車のヘルスチェックがスマホでわかる
  • 盗難の検知追跡エンジンの再始動停止

サーバーレス

  • 日中と夜でアクセス数の差が顕著
    • 通勤や業務で車に乗る人が多い
    • サーバーレスなら不必要にリソースを確保しなくていい
  • ライフサイクルが長い
    • 買い換えるまで7〜8å¹´
  • コネクティッドカー国ごとにまだ法規制が違う
    • 国ごとにプラットフォームを確保
    • サーバーレスならシェアの大きい地域と小さい地域に合わたサイズにできる
  • データは蓄積せずにリアルタイムで流している

アーキテクチャ

指針

  • 十分にシンプルな粒度
  • ライフサイクルが異なるコンポーネントを自立
  • プロセスをステートレスに

アーキテクチャスタイル

  • Nティアー
    • 役割に応じていくつかの層に分割
    • Gateway
    • Logic
    • Data
  • ウェブキュー/イベントドリブン
  • マイクロサービス
    • ライフサイクルを共有できる単位のまとまり
  • 車載デバイスと地域サービスをつなぐプラットフォーム

AWSのサービス

開発の課題

クラウドで動かさないといけないのでテストしづらい

  • CI/CDでテスト実行環境整備
  • サービス単体テスト
    • LocalStack
    • プロキシで向き先無理やり変えてテストしてる
  • サービス間連携テスト
    • Karate

全体のトレーシングが難しい

  • ログはCloudWatchに
  • 想定以上にコストが高くなるから注意
  • X-Rayで分散トレーシング

自動スケール便利だが問題になるケースも

  • Lambda失敗して再試行するようにしてた
    • 再処理のLambdaが数千実行されてしまった
    • 同時実行数の上限はアカウント単位
    • 他のLambdaの起動を妨げる危険性
    • 変に上限までいかないように関数ごとに設定する

All You Need Is JavaScript

  • Jensen Hussey / Cloudflare

Cloudflare

  • 世界中にデータセンターがある
  • ユーザに近いデータセンターでJavaScriptを実行することができる

なぜJavaScript

  • 一番使われている言語だから
  • サーバーサイド
    • Node
  • モバイル
    • ReactNative
  • ネイティブ
    • Electron
  • サーバーレス
    • Cloudflare Workers

Cloudflare Workers

  • ServiceWorkerをベースに考えられたもの
  • v8で実行される
  • WebAssemblyにも対応している

Zero Scale Abstraction in Knative Serving

Knative

  • Build
    • 卒業してなくなった
    • Tektonになった
  • Serving
  • Eventing

Knative Serving

  • HTTPリクエスト駆動でスケールする
  • 素のk8sを使うとyamlをたくさん書かないといけない
    • Knative使うと簡単になる
  • Kanative Serviceを書いていく

事例

  • なぜKnative？
    • k8sを抽象化できるから
      • ネットワークのレイヤーも含めて抽象化
    • yaml地獄から脱却
    • ゼロスケールできること
      • パフォーマンス < 可用性 のサービス
    • Dual Stack
      • knativeとk8sのリソース併用
    • Portability
  • イベントを受けて処理をするところだけzero scalingを使う
  • Eventingはまだ未成熟だから採用見送り

空調設備向けIoTシステムにおけるクラウドランニングコスト

ダイキン工業とIoT

システム規模

  • 各機器から毎分データ発生
    • 膨大なアクセス
    • 高い処理性能とスケーラビリティ
    • 無限に発生するデータを扱えるストレージ
  • スモールスタート
    • 徐々に接続する機器を増やしていく
  • => サーバーレスでNoSQLで

サーバーレス開発

  • サーバーレス開発はクラウドランニングコストとの戦い
    • 目標のランニングコスト以内で動くシステムを作れるかどうか
    • IoTのように負荷が高いシステムだと従量課金でもコストは嵩む
    • サービスごとの課金体系を把握し設計する

システム構成

空調機 -> AWS

  • 変化のあった項目を毎分送るようにした

アプリ -> AWS

  • 一度のコールで同時に複数機器のデータを取得
  • 毎分データを取り出す

ランニングコスト

  • コストのかかる部分
    • Dynamoへの書き込みでのWCUコスト
    • データ取得時のLambdaの処理時間
  • DynamoDBのデータ構造が肝になる

DynamoDBのデータ構造

  • 数十kmの項目があると一部だけ更新する場合もWCUを消費してしまう
  • 運転データごとにアイテムをわける
    • 1機器Nアイテムとしてデータを持つ
  • Lambdaからアクセス時に機器数×N個分アクセスしないといけない
    • Partition Keyを建物IDとして建物ごとにまとめて取得できるようにした

まとめ

  • 今回の要件は書き込みは少しずつ、読み込みはまとめて
  • 要件にあった構成にすることでコストを削減できる
  • DynamoDBは書き込みのほうが読み込みより10倍課金額が高い

ISPがサーバレスに手を出した

ISP

  • Internet Service Privider
  • 家 - 回線 - ISP - インターネット

サーバーレスどこで使ってるか

  • 通信する前にルールを取得する必要がある
    • そのAPIをサーバーレスで作ってる

サーバーレス以外の選択肢

  • 選択肢
    • 物理サーバ
    • 自社IaaSサービス
    • 他社IaaSサービス
  • 納期3ヶ月
    • サーバーレスじゃなきゃ無理

社内基準と通信事業としての基準

  • 社内クラウドを使わない理由
    • IPv6対応してなかった
  • 信頼性の担保
  • 100万ユーザついているサービスが1時間止まると総務省に報告しないといけない

IPv6の受難

  • API GatewayがIPv6対応してない
    • CDNかませた

リリース後

テストの自動化

  • 全般
    • ローカルで軽量に行えること
    • デプロイして行うテストは最小限に

ローカルでテスト

  • Serverless Frameworkとプロアグ員を駆使
    • serverless-offline
    • serverless-dynamodb-local

負荷試験/長時間試験

  • Gatlingで叩いてる
    • レポートが見やすい
  • テストをやって・・・
    • DynamoDBのaute-scaling忘れに気がつくことができた

CIパイプライン

  • GitLab CI/CD
    • ローカルでしか動かないということがないように
    • dockerコンテナで実行することで環境が汚れない
    • commitとテスト結果をバインドすることで証跡を残せる
  • serverless-offlineのテストとかをCIで動かしてる

Infra as Code

  • Serverless Frameworkとにかく便利
    • ローカルでのテスト
    • 本番へのデプロイ
  • Azureは対応してるのが多くない
  • AWSもすべてをコード化できるわけではない
    • sls deployのあとにaws-cli使ってるところもある
  • 構成変更
    • 移行後の構成をsls deploy
    • 切り替えて古い方をsls remove

AWS Lake Formation で実現、マイクロサービスのサーバーレスな分散トレーシング

背景

  • aiboã‚„Multifunctional Lightなどのバックエンドをサーバーレスで作ってる
  • マイクロサービス構成
  • 呼び出しチェーンが長い
  • 非同期も多い
  • クロスアカウントやオンプレとの連携も
  • 1ヶ月立ってから問い合わせや障害のトレースをすることがある

分散トレーシング

  • 分散アーキテクチャの処理の可視化や追跡性を向上させるための仕組み
    • どのサービスをどういう経路でたどったか
    • どこにどれくらい時間がかかったか
  • 共通のIDを受け渡していって経路を特定できるようにする

Lake Formation

  • 複数のAWSアカウントにまたがったログを集約分析できる
  • サーバーレスで実現できる
  • リアルタイムな分析はDataDogで長期的に残しておくのはLakeFormation

トレーシング基盤の構成

  • Step Functionsでログの出力
  • Lake Formationで各アカウントからログを集約

トレーシングIDの取得と伝播

  • X-Rayだけでは非同期イベントのトレースが困難
  • それぞれ工夫して対応した

Don’t think Serverless Security, think Application Security

  • Ido Neeman (Nuweba)

サーバーレスは新しい攻撃の窓口になりうる

  • イベント駆動アーキテクチャはサーバーレスに限った話ではない
  • むしろサーバーレスの方がセキュアな場面もある

サーバーレスはマネージしにくい

  • 小さい単位の関数にすることで管理しやすくなる

サーバーレスで過剰なアクセスがきたらどうするか

  • スケールするのが仇となって大量の課金につながる
  • 関数ごとに制限を設定しておく

サーバーレスの実行権限が広くなりすぎないか

  • IAMの権限を最小限にしぼっておくこと

Azure でサーバーレス、 Infrastructure as Code どうしてますか？

  • Kazumi Ohira

Infrastructure as Code

  • インフラのリソース構成/管理をコードで行うこと
  • メリット
    • 自動化できる
    • ミスが減る
    • レビューしやすい
    • バージョン管理できる

クラウドにおけるリソース管理

  • IaaS
    • Terraform
    • AWS Cloud formation
  • Container
  • Serverless

AzureでIaC

  • ARM templateを使う
    • 冪等性を管理してくれる
    • エラーハンドリングしてくれる
    • 差分デプロイ並列デプロイできる

The hidden cost and technical debt of running huge Serverless service on production

  • James Nguyen / MaaS Global

クラウドサービスを使うこと

  • クラウドベンダーに預けてるデータが壊れたら？
    • 最近もAWSの大規模障害があった
  • 技術的制約
    • Lambdaで最新のNodeが使えるようになるまで3ヶ月くらいかかる
    • 最新の情報を入手してアップデートし続けないといけない
      • 知らないところでAPIが廃止されてしまわないように
    • よりよいサービスに置き換わっていくこともある
      • 状況に合わせて移行していく必要がある
  • ベンダーロックイン
    • マルチベンダーは簡単ではない
    • Serverless Frameworkで抽象化はできる