- ServerlessDays Tokyo 2019に参加してきました。
- 事例紹介のセッションではかなり踏み込んだ設計の話をしてくれることが多く参考になることが多かったです!
タイトル | 発表者 |
---|---|
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
- WebApp
- Nuxt
- Laravelで認証
- PwoerBIで作ったレポートをiframeで呼び出し
サーバーレスで作ったメリット
- 開発運用コストが従来のモノリシックより少ない
- 責務分離が自然と行われる
- 将来的にスケールしても問題ないと楽観視できる
- 不要になったパーツを捨てやすい
- 分業協業しやすい
Keynote
- Keisuke Nishitani (AWS)
Event Driven
- LambdaはサーバーレスよりもEvent Drivenをキーワードにしたサービスだった
- 状態の変化をイベントとして捉えて処理を実行する
- Event Driven出ない場合処理が増えると呼び出し元にも手を入れないといけない
- Event Drivenならサブスクライブを追加するだけ
- 疎結合
- 分離して開発できる
Lambda
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
サーバーレス
- サーバの抽象化
- イベント駆動型
- 従量制課金
すべての依存は障害になりうる
- レースコンディション
- ネットワーク障害
- レート制限
- ハードウェア障害
- => 再試行のデザインパターン
グローバル展開のコネクティッドカーを支える大規模サーバーレスシステム事例
はじめての大規模アジャイル
トヨタのコネクティッドサービス
サーバーレス
- 日中と夜でアクセス数の差が顕著
- 通勤や業務で車に乗る人が多い
- サーバーレスなら不必要にリソースを確保しなくていい
- ライフサイクルが長い
- 買い換えるまで7〜8年
- コネクティッドカー国ごとにまだ法規制が違う
- 国ごとにプラットフォームを確保
- サーバーレスならシェアの大きい地域と小さい地域に合わたサイズにできる
- データは蓄積せずにリアルタイムで流している
アーキテクチャ
指針
- 十分にシンプルな粒度
- ライフサイクルが異なるコンポーネントを自立
- プロセスをステートレスに
アーキテクチャスタイル
- Nティアー
- 役割に応じていくつかの層に分割
- Gateway
- Logic
- Data
- ウェブキュー/イベントドリブン
- Webプロセス
- インテグレーションコンポーネント
- Workerプロセス
- マイクロサービス
- ライフサイクルを共有できる単位のまとまり
- 車載デバイスと地域サービスをつなぐプラットフォーム
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
- Tsubasa Nagasawa (CyberAgent)
Knative
Build- 卒業してなくなった
- Tektonになった
- Serving
- Eventing
Knative Serving
事例
- なぜKnative?
- イベントを受けて処理をするところだけ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がサーバレスに手を出した
- 伊藤良哉 & 松田丈司 (NTTコミュニケーションズ)
ISP
- Internet Service Privider
- 家 - 回線 - ISP - インターネット
サーバーレスどこで使ってるか
- 通信する前にルールを取得する必要がある
- そのAPIをサーバーレスで作ってる
サーバーレス以外の選択肢
- 選択肢
- 物理サーバ
- 自社IaaSサービス
- 他社IaaSサービス
- 納期3ヶ月
- サーバーレスじゃなきゃ無理
社内基準と通信事業としての基準
IPv6の受難
リリース後
テストの自動化
- 全般
- ローカルで軽量に行えること
- デプロイして行うテストは最小限に
ローカルでテスト
- 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
- 切り替えて古い方を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
- Dockerfile
- Docker Compose
- Kubernetes
- Serverless
- ???
- クラウドごとに異なるけどどうする?
AzureでIaC
- ARM templateを使う
- 冪等性を管理してくれる
- エラーハンドリングしてくれる
- 差分デプロイ並列デプロイできる
The hidden cost and technical debt of running huge Serverless service on production
- James Nguyen / MaaS Global