2018/9/29 Serverlessconf Tokyo 2018に参加したので、見たセッションのメモを残します。前日のワークショップも参加したので、そちらもそのうち感想を書こうと思います。
イベント情報
Serverlessconf は、サーバーレスアーキテクチャを用いたアプリケーション構築における知見の共有を目的とした、コミュニティ主導の技術カンファレンスです。
サーバーレスアーキテクチャは、開発者のひらめきやクリエイティビティを素早くWeb、モバイル、IoT、VUIアプリケーションなどとして実現ができ、スケーラビリティやセキュリティ、インフラの保守といった多数の力仕事から解放されることができる新たなパラダイムシフトです。
資料はまとめてくださっている方がいました。
【Serverlessconf Tokyo 2018】カンファレンス資料まとめ - Qiita
企業向けのServerlessについて Chris & Marie / MS
- IaaSはカーディーラー 車を買う、PaaSはレンタカー 使わなくてもお金がかかる、Serverless は Uber
- 企業向けのアプリは厳しい要件がある
- パフォーマンス
- スケーラビリティ：スケールキャパシティ＆スケール速度 − Azure新機能
- Azure Functions 2.0:HTTP Throwput 75%向上
- Azure Premium Functions 発表
- サーバレスとPaaSのハイブリッド
- VM最大値を設定可能、スケールアウト、ロングラン、コールドスタート無し
- アクセス制御:認証、承認、権限の取消し
- 機密情報管理:暗号化キー、アクセスキー、その他
- 監視:ロギング、モニタリング
- Azure Functions
- オープンソース・コンテナ上で動作可能
- Azure Functions 2.0 はオンプレ,IoT,開発端末でも同最可能
- C#,Java,JavaScript,Pythonサポート
- 関数オーケストレーション
- Azure Durawble Functions
- 関数チェーン、非同期HTTP-API、ファンアウト、ファン員、長時間モニタ等
- Azure FunctionsはOSS
- IssueでMSの開発者と直接やりとりできるしPR送っても良い
サーバーレスなシステムの頑張らない運用監視 ～MonitoringからObservabilityへ～/Takanori Suzuki
- サーバレスでファンクション数など増えてくると処理の流れが分かりづらい、運用監視が難しい、あらかじめ設計が必要
- 課題
- サーバはなくてもファンクションやサービスは監視が必要
- イベントドリブンはどこから呼び出され、どこで障害が発生しているかトレースが必要
- どれだけリソース消費しているか分かりづらく、最適化し辛い、思わぬコスト増に繋がる
- 単純なログ監視の問題
- 問題発生時のデバッグ効率が悪い
- 問題が発生してから出ないと気づかない
- 監視できていない内容が多い
- X-RAY：分散トレーシング
- サービスマップ：Lambda,DynamoDB,Kinesis,SNSなどの呼び出しの関連を俯瞰
- 実行状況：処理時間、エラーパーセンタイル を確認
- トレース詳細：何の処理にどのくらい時間がかかっているか
- Observability：可観測性
- 簡単にシステムの状態を把握したり、動作を確認したり出来ること
- Monitoring ＋ トレーサビリティ
- Cloudwatch Logs：ログ別れてて辛い
- CloudWatch Metric：登録めんどくさい
- X-Ray：基本的に使うようにしている
- データ取るだけではObservabileになるわけではない
- アラート＋見せる化
- CloudwatchLogsのログ(error等)を検索してSlack通知、Logsへリンク
- Lambda実行時間；実行時間80％超でSlack通知、Metricへリンク
- DynmoDBのR/Wキャパシティ：キャパ80%超でSlack通知、Metricへリンク
- バッチの処理時間、バックアップの実行結果：正常終了をSlack通知
- ログ、メトリック、トレースは各クラウドベンダが提供している
- サーバレス向けのモニタリング：Thundra,IOpipe、Espagon
- ツール入れる事よりも、継続的に活用、拡張していくことが重要
サーバレス時代の運用監視(GS2)
- 汎用的なゲームサーバをサービスしている
- 課金情報管理とか、認証管理とか、体力管理とか
- 可視化
- DataDogダッシュボードをオフィスに掲示
- 実際に監視している項目
- 基本メトリック
- 秒間アクセス数
- サービス利用者起因のエラー数／GS2起因のエラー数
- 想定外の例外発生数
- Google App Engine リミット数
- サービスパフォーマンス
- API-Gateway、Lambdaレスポンス時間
- 認証／許可検証にかかった時間、DynamoDBのIOにかかった時間
- キャパシティ監視
- DynamoDBで最もキャパシティを消費しているテーブルの使用率
- Lambdaの同時実行数のアカウント上限値に対する使用率
- アラームの状態
- アラームがすべてOKか
- アラームが出てるとすればどのカテゴリか
- 直近4時間／一週間／月間 のAPIコール数
- 前の同時間帯のグラフと、重ね合わせ（増えてるのか減ってるのか）
- 直近4時間のトレンド（上昇傾向など判断）
- 利用されているマイクロサービスランキング
- レスポンスタイムのワーストラインキング
- インフラのコスト
- アカウントやプロジェクトごと
- 異常な増え方はしていないか
- 売上げ
- 基本メトリック
- DataDogの設定のやり方説明 − Slack通知
- Cloudwatch Logs だとどのログでエラーが起きたのか、見つけるの大変
- DataDog Logs で見れちゃう
- タグ分け、フィルタ（レスポンス時間閾値、内容 等）
- 可視化
- DataDog サービスマップ
- X-Rayみたいなやつ
- Lambdaとか、サーバレスにはいまのところ使えない😭（Agentが必要）
- インシデント管理みたいなボードもある
Monitoring Serverless Applications - Should you worry? / Nitzan Shapira, Espagon
- Co-Founder, CEO @ Espagon / Software Engineering > 12 years
- Observability, Monitoring application / Espagon
- Monitoring: Why do you need it?
- Track service health / Troubleshoot and fix / Optimize performance and costs
- From Monorice to Microservice / serverless
- pay / use
- autoscaling
- development velocity
- application become : Highly distributed / Highly event-driven
- System Health = Functions health ??
- The SYSTEis more than function
- Track SYSTEM health
- SYSTEMs are : Functions / APIs / Transactions
- you need to track ASYNCHRONOUS EVENTS
- Transactions
- Tracing asynchronous invocations & trace non-AWS resources too
- Distributed tracing, you need to trace trouble
- Manual traces/instrumentation
- Before/After calls at end of each micro-service
- High maintenance / High potential of errors
- Scanning functions - the easy way
- Scanning Cloudwatch Logs
- Cloudwatch become highly throttled
- requests took a very long time
- Scanning Cloudwatch Logs
- serverless apps are VERY distributed
- complex system have THOUSANDS of functions
- what about the DEVELOPER VELOCITY
- AUTOMATION can help too keep up with the development speed of serverless
- Existing solution: X-RAY
- Tracing outbound request
- No distributed tracing/ asynchronous events tracking
- Existing solution: X-RAY
- ESPAGON DEMO: traceability
- functions and one transaction are very important for system tracing
- in serverless, time is Money (doesn't pay at idle)
- how much time do you really spend? (need to trace)
- Infrastructure overhead
- Our own code
- API calls
- functions statistics / invocation / cold start etc...
- Observability
- Dynamic service map(Observability)
- Business Flows
- automatic functions analysis
- End-to-End serverless tracing
Serverless Architecting & NoSQL Data Modeling / Serverworks TERUI
- CNCF serverless whitepaper
- 分割・統括／Observerbility の問題
- AWS App Sync が今後重要になるかも
- serverlessの課題はMicroservicesと同じ
- 強いサービス依存という問題もある
- EVENT-DRIVEN & EVENT-SOURCING
- 目的を果たすための最適解は異なる
- メッセージング
- 同期/非同期
- インタラクティブ/PubSub
- データストア
- スケーリング
- データアクセス
- 実行方法
- 直列/並列
- 決定的/非決定的
- メッセージング
- 目的を果たすための最適解は異なる
- すべてはEVENTとACTIONの組み合わせである
- 同期；API Gateway
- 非同期
- 直列:Kinesis stream
- 並列:SNS/SQS
- その他:Step functions
- 非同期ベースで考える
- エラーハンドリング：リトライ可能な処理はリトライする/リトライできないエラーも１つのイベントと考える
- モニタリング／トレーシング
- 管理方法
- CloudFormation
- SAM/Serverless Framework
- 依存性の管理、EventSourceとAction（Lambda）の紐づけ
- 宣言的
- Ref
- ImportValue/ExportValue
- CFn
- EventSource/Action単位でStackわけて
- 明確な分離基準
- 宣言的な紐付けができる
- EventSourceを接続点として依存関係を集約する
- EventSource/Action単位でStackわけて
- CloudFormation
- Integration Testが可能に
- ステージ名をパラメータ化、EventSourceを入れ替え可能
- 定義を変えずにMock化したIntegration Testができる
- OutputsからEventSourceを取得してテスト用のEventを発行
- Actionから発行されるEventの対象も童謡に検証可能なものに置き換える
- データストアも置き換え可能
- テストではEventとそれに対するActionを保証することを重視する
- ステージ名をパラメータ化、EventSourceを入れ替え可能
- データストアは？
- DynamoDB Best Practices
- Schema-lessとは:List/Mapが持てること、すべてのAttributeが必須じゃないこと
- ではなく、何でも突っ込めることができるので、適切に分散させられればテーブルを分ける必要はない
- アプリケーションとデータモデルは同時に設計する
- 書き込みと読み込みで同じデータを扱う必要はない
- 書き込みの原単位を考え、アイテムにまとめることで整合性を守る
- 読み込みは結果整合性を受け入れ、効率の良いデータを生成していく
- DynamoDB Best Practices
- 知っておくべきこと：各データストアの特性
- DynamoDBならPartition Key SortKeyの分散の仕組みとか
- データの整合性を守る仕組み：ACID
- データアクセス：B-Tree
- DBの基礎的な知識
- データの原単位を守ることが重要:ドメインをまたがないこと