Serverless Conf Tokyo 2018 に来ている記事5 : Game Server Service Session #ServerlessConf #serverlesstokyo

毎年参加しているServerless Conf Tokyoです。3回目になります。

http://tokyo.serverlessconf.io/tokyo.serverlessconf.io

他のセッション

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

引用は私のコメントです。

目次

Title

Game Server Service サーバーレスアプリケーションの監視・運用

Speaker

丹羽一智

@kazutomo

Slide

従来のインフラ監視

• Load Average
• CPU Average
• Memory Usage
• Disk IO

を見てきた

Serverless 監視

これらは不要だけど、サービスは正しく動いているのか、コンポーネントが動いているのかを確認していくのが重要になる。 つまり

• サービス監視
  • サービスが正しく提供されているか判断する指標
• コンポーネント監視
  • コンポーネントが動いているのか

レイヤがインフラ生からサービスの要素に変わっているので、そうなりますね。

コンポーネント監視

キャパシティ管理、上限革の必要な項目

• Lambda の同時実行数
• API GAteway へのRequest/Sec
• DynamoDB のキャパシティ使用率

障害発生時に障害店を特定するための項目

• API Gateway の応答時間
• Lambda の実行時間
• DynamoDBの処理時間

などが重要

マルチクラウドでG2S は提供

AWS/GCPで提供される視覚表示は、折れ線グラフになっており指標とあってないこともおおい。

そのため、Datadog に大型モニタに表示して席から見てる。

監視内容

かなりDatadog の利用方法にそった監視方法になってる

基本メトリック

• 秒間アクセス数
• サービス利用者起因のエラー数 : User Error
• GS2 のエラー数 : Backend Error
• 想定外の例外発生数 : Fatal
• Google App Engine のクォーターリミット

サービスパフォーマンス

所要時間が重要。

• API GAtewya Response
• Lambda Reponse
• Lambda Code Response
• Auth Duration
• DunamoDB IO

Datadogのしきい値、色変化で見てる。

キャパシティ監視

• DynamoDB で最もキャパシティを消費しているテーブルの使用率
  • 個別のテーブルはどうでもよくて、一番使っているやつを知る必要がある
• Lambda の同時実行数のアカウント上限値に対する使用率
  • 同時実行の多いやつはどれだ！
• Lambda/DynamoDB のスロットル発生回数

アラーム状態

• アラームがすべてOKな状態か

直近4時間のAPIコール数

• 点線は1週間前の同時間帯のグラフ
• 直線は直近4時間におけるトレンド
• 今どの程度のアクセスがあるかを可視化

Datadog のフィルタ機能で、移動平均やトレンドを出してる

一週間前の、とかトレンド、とか自分がやってるのと同じことやってる....

直近4時間のAPIランキング

• 利用されているマイクロサービスランキング
• レスポンスタイムのワーストランキング

ここも全く同じ....

直近一週間のAPI ランキング

期間を変えると見る要素かわりますからねぇ

直近1ヶ月のAPIコール数

• 点線は1ヶ月前の同時間帯のグラフ
• 直線は直近一ヶ月におけるトレンド
• 跳ね上がっているのは、クライアントの実装ミスによってビジーになったこと

インフラのコスト

サービスの提供にかかっているインフラコストの可視化

異常な増え方をしていないかを視覚化

売上

サービスの売上可視化

• 24h
• 一ヶ月

ここまで、 黒騎士と白の魔王を支えるDatadogを使ったモニタリングで書いた内容とほぼ同じ

Datadog でどう監視するのか

プラグインの設定

• AWS アカウントと、AssumeRoleに使用するロールの設定
• どのサービスのメトリックを収集するか設定
• どのサービスにどのタグを設定

コンポーネントの追加

どのようそを関しするよ、とかをScreen Bpard に投げてる

メトリックの設定

どのメトリックのをせてい

• レンダリングするデータソースを設定
• SelectyaGroupBy もできる
• フィルタで移動平均とかもだせる

値の範囲でダッシュボードに表示する色を設定可能

• 異常値になったときには色が変わるようにすることええ、すぐに異常でアルことを認識できるように

想定外の例外が検出時の対応

どのアカウントで何が発生しているの....?

• Lambda の CloudWatch Logs は厳しい
  • Lmabda が実行されたコンテナごとに別れている
• そこでDatadog Logs
  • すべてのアカウント、プロジェクトのエログを集約
  • フィルタリングも爆速

たとえば、マイクロサービスを絞り込んだり、ファンクションで絞り込んだり、ステータスコードで絞り込んだり、レコードを選ぶと詳細が見られる。ここで、リクエストの内容やレスポンスの内容を埋め込んでいる。

ダッシュボードのメトリックからログに飛ぶことが可能。

• API Error -> View related logs > タグで絞り込んだ状態のログを見られる

ログの取り込み方

TCPでつないで投げ続けるだけ

サービスマップ

X-Ray の100倍まし。

ノードを選択するとより細かい利用が見られる。

何がいいかというと、プラットフォーマーが提供しうるサービスとは異なり、クラウドをまたげる。 (が、サービスマップはサーバーレスからは利用できない、エージェントインストールが必要)

Q&A

インシデントがあったときに連動方法は?

異常はダッシュボードで確認。 ここからDynamoDB用など詳細のダッシュボードでわかるようになっている。 あとは、じょじょに上がっているのであればキャパシティ問題。 スパイクなら、異常が発生しているのかの確認。 スパイクを起こしているテーブルから、そのテーブルを使っている関数をたどる。

ダッシュボードドリブン + Slack での通知でハンドルしている。 異常 -> 正常化は、マニュアルでやっている(運用自動化はしていない)

キャパシティなどは、日常的に上がっているとき -> 日常的に改善が必要と認識。

Slack 通知 = 異常 = 人間が対処するしかないという認識。

インシデント管理

スクリーンボード 以外に、タイムボードでメモを残している。 あとは、 Confluence にメモ残している。(フルマネージドなので、クラウド障害じゃないと障害にナリにくいのでノウハウが溜まりにくい)

ちょっとインシデント管理厳しいですよねぇ。Datadogのメモはこういうの弱いので、Timeline に流して、自動的にesaにpostあたりがいいかなぁ。 GitHub Issueもインシデント管理にそこまで強くいないしなぁ。(悪い選択じゃないので、こっちでもいい)

Serverless Conf Tokyo 2018 に来ている記事4 : Acroquet Technology Session #ServerlessConf #serverlesstokyo

毎年参加しているServerless Conf Tokyoです。3回目になります。

昼を食べると眠くなるので、最近はランチを取らない様になってきました。サクッと集中してやって、さくっと、ね。

http://tokyo.serverlessconf.io/tokyo.serverlessconf.io

他のセッション

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

引用は私のコメントです。

目次

Title

サーバーレスなシステムの頑張らない運用監視 - Monitoring からObservabilityへ

Speaker

鈴木 貴典 @takanorig

資料

ServerlessConf Tokyo2018 サーバーレスなシステムのがんばらない運用監視 from Takanori Suzuki

サーバーレスシステム開発バックグラウンド

AWS を利用している。 主にServerless Framework をつかっている。

サーバーレスシステムの運用監視の課題

サーバーレスはサーバーは見なくてもいいけど、アプリケーション監視としては変わってない、むしろモノリシックよりも大変。

• サーバーはなくても、ファンクションやサービスの時状況は関しが必要
• イベントドリブンなシステムは、どのようによびだされているか、どこで障害が発生しているのかトレースが大変
• どれだけリソースを消費しているか、わかりにくいので最適化しにくい

違い	メリット	・デメリット
従来	アプリ構築簡単、デバッグ、運用もわかりやすい	冗長化考慮必要、サーバー管理必要
サーバーレス	開発スピードUP、拡張性、冗長化は任せられる	デバッグ難しい、システム細分化、分散化する

つまり、開発容易性、スピードは向上するけど、運用監視は複雑化する。

第一次監視 : CloudWatch + 人力デバッグ

デバッグ効率が悪い、原因特定、解決まで時間がかかる。 問題が発生しないと気づかない。 監視できていない内容も多い。

• 監視自体のメンテナンスに手間がかかる
• だんだんとダッシュボードなどをみなくなる

第二次監視 : CloudWatch Logs の内容から自動エラーチェック、X-Ray導入

CloudWatch Logs を使って、自前で監視アプリを作ってエラーチェックを開始した。 X-Ray でデバッグ構築や監視が向上。

from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all

patch_all()

X-Ray でサービスマップ、実行状況、トレース詳細がわかる。

実行状況では、処理時間のパーセンタイルやエラーの発生状況を確認できる。 トレース詳細では、処理ごとの時間が見える。

第三次監視 : Observability

重要なのは Observability = 可観測性

Monitoringの上位互換的に。 簡単にシステムの状態を把握したり、アプリケーションの動作を確認したりできること。 トレーシング(X-Ray)、メトリクス(CloudWatch)、ロギング(CloudWatch) を包括している。

• CloudWatch Logs -> ロギング は、Log Streams が別れていて間作しにくいしきつい
• Cloud Watch Metrics -> メトリクスは、Lambda 関数や　DynamoDBのテーブル追加時に自分で追加する必要あって吊上
• X-Ray : トレーシングは、とりあえず有効化しておけ

Distributed Systems Observability より

Logging / Metrics / Tracingがあっても、Observability ではない。

アラート化 + 見せるか

• CloudWatch Logs に出力されるログを一定時間ごとにチェック
  • メトリクスフィルタは正規表現使えない、サブすくしプションでも都合が合わない
  • Lamnbda で横断的にチェック可能にした
• 特定のキーワードを正規表現でチェックし、その内容を検出した際に、該当部分のログをSlackに通知
• Slack には、Cloud Watch Logs へのリンクを設定をし、それをクリックしたらダイレクトにログの内容を確認できるようにしている
  • 問題発生箇所、前後の動きがわかるように

当然ですが、リンクはだいじ。

リソースの監視として、　Lamnbda の関数実行時間(制限の80%超えたら)、DynamoDBのキャパシティの消費量(キャパシティの80%超えたら)を見て通知かけている。

サービスの正常性確認として、異常障害以外に、サービス正常可能確認もしている。 テキストでわかりにくいものは、ヘッドレスブラウザを利用して画面キャプチャを通知。(Lambda でキャプチャとって数値)

Datadog の利用を検討してやろうとしている。 Lambndaは、関数増えても自動追加される。時間は絶対時間になる。 DynamoDBも、テーブル増えると自動追加されるし、キャパシティみれる。

どのようなツールを導入するにしても、対象となるサーバーレスシステムに対して、重要なのは、継続的に活用、拡張していくことが重要。

当然DataDog 使うんだけどなぁ.... 考え方は基本のキですね。やり方が時前になるとやっぱりびみょいなぁ。なんというか、自前でやる時点で、(開発し続けないと)継続性が落ちるので厳しい

改善事例

想定外に時間がかかる処理の早期検出

バッチ処理にLambda を利用。 安全のため、5分(Lambda の上限) していた。

処理のどこが時間かかっているか、Step Functions の実行詳細から時間を確認、X-Ray のトレース詳細でどの処理か確認↓。 結果、DynamoDBのTTLの設定質を取得しており、1テーブルあたり3病時間がかかっていた。 全テーブルの処理をしていたので、処理時間がかかっていた。

DataDog で気づけるじゃん.... APM 使えば... はないな、ここはX-Ray のほうがいい。

キャパシティの最適化

Lambda 実行時に　DynamoDBからスキャンで複数件のデータを取得。 Redis を使うほどの高速性は不要、コストをかけたくなかった。

Scan はもちろんなるべく使わないほうがいい(特にサーバーレスはスケールするので危険が危ない)

どの程度キャパシティを設定するのか予想しにくい。そのくせ、キャパシティ釣果でデータが取得できなくなったてサービスへの影響が大きい。

正常時 : 10ms 異常時 : 159msかかる。アクセスが増えると処理時間はより長くなり、サービス障害につながる。

この状況からキャパシティの最適化をおこなった。

普通の監視では、処理時間に気づけ無いけど気づけた！

気づけ無い....だと.....

ついでに、同時実行数が多いとLambda の初期化(AWSの準備)に待ちが発生する。 関数の実行実行数を制限して、必要以上にリソースを消費されないように調整。

いいプラクティス。AWSが同時実行数多いと時間かかるのが悪いw

第四次監視 : IoT、機械学習

やりたい

まとめ

普通のアプリ監視と同じで、監視するだけじゃだめなので可視化、気づける化は重要ですねぇ。X-Ray 以外だと、StackDriver ですねぇ。AzureがInsightだけど微妙すぎる。

Serverless Conf Tokyo 2018 に来ている記事3 : Recruit Session #ServerlessConf #serverlesstokyo

毎年参加しているServerless Conf Tokyoです。3回目になります。

http://tokyo.serverlessconf.io/tokyo.serverlessconf.io

他のセッション

tech.guitarrapc.com

tech.guitarrapc.com

引用は私のコメントです。

目次

Title

The Design for Serverless ETL Pipeline

Speaker

山田雄

@niiyan

秋本大樹

白鳥昇治

@irotoris

資料

The Design for Serverless ETL Pipeline (48:9) from Shoji Shirotori

導入するサービス

リクルートの分析基盤。ここに各種リクルートサービスのデータを入れている。

これまでの流れ

運用しつつ改善を繰り返してきた。

• 2013 : Hadoop(オンプレ) + RedShift
• 2014 : TreasureData
• 2016 : RedShift MultiCluster
• 2017 : BigQuery + DataLake
• 2018 : TreasureData -> BigQuery, RedShift Spectrum, RegShift -> Single Node

2018 は構成の新婦柄を目指してるのね。

レガシーな構成のつらいところ

どうつらいのかというと、技術のつぎはぎがもっとも厳しい

• 800行のShell Script
• 本番環境が分離されてないので、開発いれてからじゃなくていきなり投入が必要...
• Python でSegmentation Fault
• 複数のシステムをツギハギするスケジュール実行
  • 終了するタイミングを見計らって後続の処理を実行
• データ量に関連した処理の長時間化

あるあるつらさだ。スケジュール実行最低に面倒なやつ。Observable に購読するか、Push されてこないと延々ときびしい、かつデータがただしいかみないとか.... 長時間化はパラレル処理かなぁ?いけるなら。

分析基盤の特性 : データ間の依存関係

事業データを正規化して、データウェアハウス (RedShift / BigQueryなど) にいれる、で分析者が使うデータま０とを生成する。

ETL分析のものは優先度高く。アドホック分析は優先度落とす。など、優先度管理が必要。 優先度を変更する = 運用負荷につながっている。

そのため、JP1 でイベント受信機能を使って、優先度を実現している。優先度高いものが終わるまで、優先度低いものが開始せず、高いものが終わったら低いものがキックされるようにしている。

障害リカバリの大変さが半端ない

スケジュール実行での運用は、一度障害が起こるとずっと処理を待ち続けて、後続を流す、という運用が厳しい。 -> データドリブンに変更したい。

1つの実行単位に複数のテーブルを含めているので、テーブルごとに実行できない。

あるあるすぎる

自前サーバーでの開発が辛い

テスト環境がないので気軽にテストできない 本番にえいきょうが出るので、古いバージョンでのカイアh津を強いられている。 800行を超えるシェルスクリプトのメンテがつらすぎる。

なんでシェルスクリプトでかいたし..... 環境が複数あって、その環境の更新をインフラが嫌がってるのか.....

シェルスクリプトが1行ずつ読まれるから、デプロイも1行差し込めばいいじゃん。

改善プロジェクト : Migaloo (白鯨)

前回のServerlessconf Tokyo

サーバーレスおにしてサーバー管理を小さく イベントドリブンで処理をしましょう。

-> で、結果は?

データ : 増えてる 機会学習バッチのリソース使用量 : 増えてる バッチ : 1時間 -> 2時間に伸びた。

が、運用は全然なくなった。

Slack のアラート確認してるが、自動リトライ済み。 データ量もスケールするので関係ない。 システムモニタリング用途の Amazon Elasticsearch Serviice のリソース見直しの運用を実施。 AWS のSQS がおかしくなったときだけ、手動でリトライした。

今回もServerless で。

アーキテクチャ設計思想

サーバー管理を少なくパイプライン + 実行環境

データソース -> Pipeline (SQS -> Lambda -> StepFunctions) -> DataLake(S3) -> Pipeline (SQS -> Lamnda CloudWatch -> StepFunctions) -> RedShift Spectrum/BigQuery/S3

Pipeline = Step Functions + AWS Lambda で構築。

j拮抗環境あh、スケーラブルな、AWS BAtch / Glue / GKE を利用。 要件によって、一部はオンプレサーバーを利用 (じゃらん)。データ圧縮をしないとDirect Connect が詰まるので一部オンプレからServerless から呼び出しをして処理を行っている。

イベント・ドリブン

1 イベント = 1データがどこかに到達した時。 イベント・ドリブン = データが到達したときに次の処理が実行される。 (1イベント = 1 テーブル (これまでは複数テーブルをまとめて1処理 = 1イベントしていた))

Database やS3 などのイベントソースを受けて実行開始。など。

疎結合なパイプライン

RedShift = 時々メンテナンスが来るので、自動リトライ。 SQS は、リトライ = Dead Letter Queue を使って処理をしている。

1. 障害発生時の影響の小ささ、リトライ
2. デプロイは限定してそこだけに

パイプラインとスケーラビリティ + 並列数の管理

マネージドなパイプラインにより、無限にスケーラビリティが...。

でもRedShift は500接続まで。なので、この有限接続先との接続には、イベントの同時処理制御をするため、Lambda を挟んでいる。それが、RedSiftまでのPipelineでSQS ＋Lambda を行っている。(Lamnda で同時処理上限を制約)

ロード処理の宛先がスケールする場合は、気にせず実行

イベントのステータス管理と活用

メタデータ(データがどこからいつきたのか) は重要。

各パイプラインで現在の家bンとと処理ステータスを、DynamoDB を使って管理。

• Lambda の2重発火による重複起動を制御
• データロード後のマート作成実行を制御
• データロード完了時間を確認(いつデータロードが終わったかの鮮度が管理できる)

DynamoDB 使うのは筋だし、よいな。ようはスケールするKV DBなら何でもいいので、Azure ならBlob Table... 処理量でCosmos... うっ高い、使い勝手わるいな

イベントとステータスん変更履歴はRDS で管理 (DynamoDB Streams でアイテム変更をRDSへストリーミングインサート)

2000行のSQL..... その分析いやだなw

運用が楽になるロギング・モニタリング

AWS を主に使っているが、Cloud Watch Logs は見に行くい。 LogStreams が AWS Lamnda やAWS Batch で分かれるのが使いにくい。

わかる、Cloud Watch Logs 価格面でいいんだけど、めっちゃいや。

ということで、アプリケーションログとシステムモニタリングはDataDog へ。 重要な通知はSlackへ。

Lambda、AWS Batch、オンプレの様々な実行環境のプログラムログをまとめて流している。

妥当だった

Managed Service のメトリクスのアラートもDatadog に集約。重要な通知はSlackへ。 特にSQS のアラートは重要なので、キューの状況は注視。 Lambda は一度落ちるとコケるので、要注意、しきい値も常に改善したほうがいいと考え注意している。

SQS を始めとしたキューの監視がね、仕方ない。

リプレースの際の教訓

ETL 処理のリプレース処理をやっていて、2つ教訓がある。

既存の運用に設計が引きずられる

• なれた運用からの脱却
• ログの保存先の変更
• 新しいツールの学習

これらが、運用として変更時に負荷になる。 運用を替えないようにすると、今までのインターフェースに引きずられてサーバー依存の設計になりがちで厳しい。 運用も含めてリプレースの対象だという共通認識を作る。

あるあるすぎる。やりたいことにフォーカスして、ツールを変更を受け入れる、ツールに自分たちを合わせるの大事。

スコープの肥大化

今までのつらみを解消しようとして、スコープが肥大化しがち。銀の弾丸として見られるのは良くない、スコープを決めて「何ができる、何ができない、やるやらないの判断」は非常に重要。

金言。まじである。

Serverless Conf Tokyo 2018 に来ている記事2 : Azure Session #ServerlessConf #serverlesstokyo

毎年参加しているServerless Conf Tokyoです。3回目になります。

http://tokyo.serverlessconf.io/tokyo.serverlessconf.io

他のセッション

tech.guitarrapc.com

引用は私のコメントです。

目次

Speaker

Chris Gillum

@cgillum

Serverless ってServerがないのこと?

Serverless はServerを気にしなくていいという意味がある。Serverがないことではない。

ようやく、これで、面倒な言葉遊び終わってほしい....

クラウドコンピューティングを交通で例えると

IaaS : レンタカー PaaS : タクシー SaaS : Lift なりのアプリ

企業は要件を持っている

パフォーマンス

パフォーマンス要件が厳しい、Microsoft の注力ポイントはここ。

• Scale Capacity <= VM Instance のキャパシティ
• Scale out Speed <= すぐに展開できない状況でどう展開するか

Azure Functions v2 で、70% 速度が改善した。

2018/9/24 Release : https://azure.microsoft.com/en-us/blog/introducing-azure-functions-2-0/

Premium Functions がアナウンスもされた、サポートされている機能は

• Hybrid of PaaS and Servereless
• Optional Minimum % Maximum VM Count
• Rapid Scale out
• Unlimited Execution Duration
• Premium VM Sizes
• VNET Connectability
• No Cold Start

などがある。

No Cold Start がかなり嬉しい。初動マジおそだし、Ping Functions でも1台しかプロビジョンされない..... 創栄場、Always Onが別にアルけどこいつ使うと....?

アクセス制御

退職者がアクセス出来ないようにするなど必要ですyぽねぇ。

デプロイが認証情報を持ってはいけない

• 暗号化キー
• アクセスキー
• 他の秘密情報

これらは、Azure KeyVault を使って管理可能。

実際めっちゃ使ってるけど、超便利。ただ、Azure Functions との疎結合過ぎて、　Terraform 以外で管理しきれないので注意。

監視

Azure IApplication Insight で監視できるよー

見にくいねん.... 結構きらい。

FaaS Spectrum

ローカル実行デモ(Docker)

Dockerイメージが提供されている。

FROM mcr.microsoft.com/azure-functions/node:2.0

https://hub.docker.com/r/microsoft/azure-functions/

あるの！？知らなかった.... さいこうじゃないですかぁ。 docker pull mcr.microsoft.com/azure-functions/base:2.0 docker pull mcr.microsoft.com/azure-functions/dotnet:2.0 docker pull mcr.microsoft.com/azure-functions/node:2.0 docker pull mcr.microsoft.com/azure-functions/python:2.0

VS Code でブレークポイントもはれる。(拡張なし?)

HW部門が使ったVM サーバー上で利用したい -> Kubernetes 上でAzure Functions デプロイして、ワークロードに合わせる。

お金の制約しか無いなら、Azure Functions でもいい。

VS Code のExtensions で、デプロイがさくっとできる。

ここでPortal からURL もらう流れがめっちゃ嫌い..... いい加減なんとかしたいな。

サポートされている言語

• C# / Java / JavaScript + Python

関数オーケストレーション

従来の方法だと、関数の追加でキューが必要でありえんめんどくさい。

F1 > Queue > F2 > Queue > F3 > Queue > Fn > Queue n

これは今Lambda でめんどくさいやつ。Cloud Functions もか。

Azure DurableFunctions のオーケストレーションがらくなのは、オーケストレーターとアクティビティでコードで表現できる。(C# / Node でサポート)

関数チェーン、非同期API、ファンイン、ファンアウトがサポートされている。

F1 -> F2 -> F3 -> Fn

デモ : GitHub のシークレットをDurable Functions で監視....!

https://github.com/mhoeger/functions-docker-sample 参照

ふつうに有用。AWS Secret の拡張だと限定的なのでまぁいいね。

リポジトリが大きいと時間かかるので、実行時間制限がないDurable functions で対応する。

Durable Functions の callActivity待受けをyield で待ってるあたり、IEnumerator なぁ、コルーチン...

callActivityWithRetry で、リトライ制約をつけることができるのがかなりいい

いい加減Durable Functions のサンプルをリポジトリにあげておくか.... https://github.com/guitarrapc/AzureFunctionsIntroduction

オープンソース

企業が求めるのはオープンソース。

多くの改善をコミュニティからもらった。

Issue 投げてるけどコミットしてないなぁ

日本プロ野球ほげもげでは、毎日大量の写真がプロカメラマンからアップロードされる。 これまでは、毎晩この写真がだれ、とかやっていたがこれを解決した。

写真のタグ付け、自動タグ付けをしようと、Face API でやると30%程度しか自動タグ付けできなかった。(バッタは横無垢と、ピッチャーも正面ではない)

そこで、顔認識、試合データ、Exif解析、シーン解析を組み合わせることで90% まで上がった。で、この組み合わせ = ワークフロー = Durable Functions を使っている。

画像加工 -> 顔認識   -> 推定処理 -> 結果データ
        |           |
        -> 画像分類 ->

おまけ

デモが別途入れ替わっておこなれてるの最高では? 意識変わるし注目するのですごく面白い取り組み感ある

Durable Functions の良い使い方的には、Shibayan のLet's Encrypt がいいと思う https://github.com/shibayan/azure-appservice-letsencrypt

Serverless Conf Tokyo 2018 に来ている記事1 : AWS Session #ServerlessConf #serverlesstokyo

毎年参加しているServerless Conf Tokyoです。3回目になります。

http://tokyo.serverlessconf.io/tokyo.serverlessconf.io

今年も場所が変わって、東京タワースタジオなのですが、例年よりこじんまりしています。 周りにお店が少しはあるので、今までよりいいかも? (会場は古めですがこういうのでいい)

冒頭の吉田さんの挨拶のあと、AWSセッションで。これもAWSセッションのみ。

引用は私のコメントです。

目次

Speaker

Keisuke Nishitani

@Keisuke69

Serverless の価値

ビジネスを生み出すこと。 このビジネスの創出により集中するために、開発者が必要としているのは、より効率的、俊敏、スケーラビリティの高いサービス。

Undifferentiated Heavy Lifting

付加価値にならない、重い作業は小さくしたい。ビジネスロジックに集中したい。

Undifferentiated Heavy Lifting が大きいと価値が低い。(ランタイムや環境のセットアップ、プロダクションシステムのキャパシティの見積、モニタリング、スケーラビリティ確保、冗長化、認証認可、スロットリング)

Lambda がデてきた2014年

AWS の価値に、Working Backward (お客様の課題に向き合い)というのがあり、課題に対して検討して開発されたのがAWS Lambda。

• Function
• Event Driven
• Never Pay for Idle
• No Servers to manage

157機能が4年間でリリースされている。(非公開の改善はもっとある)

38% : すでに使っている (+7%) 37% : 今使っていない (-4%) 26% : 今後1年で使う

利用者のうち、69% がLamnda を使っている。

Customer Serverless

Quator ベースだと、ここ1-2年で利用が大きくなっている。 はじめは、Web/Game などのアーリーアダプターが使っていたが、エンタープライズも使い始めている印象がある。

実際、ここ1-2年で事例の発表がエンタープライズからが多い感じ?

サーバーレスの効果

いわゆる Undifferentiated Heavy Lifting なことから解放されますよ。

• サーバー管理が不要

  • とはいえ、warmup だるいんだが....

• スケーリング

  • Consumption にするべきだよねー

• 組み込まれた高可用性

  • ここはS3 障害などが無い限り、可用性はかなり高いのでよさある。

• アイドル時のリソース確保不要

  • Azure の Service Plan や Always On の違和感はこれ...

  • 0円スタートが可能、かつシームレスに秒間x0000 req までスケールする

Try and Error がしやすいのは良い環境ではある。

サーバーレスの流れ

基本構成はイベント起点。

Event Source -> Funcrion > Service 

OS のネイティブ機能もFunction で利用できて、各種言語が利用できるので、Lamnbda のための特殊な事情を考える必要はない。

TCP通信なら何でもok、UDP はだめよ。

Event Driven Service	Event Sources	Lambda Inside
AWS La,nda	S3	IoT
Amazon API Gateway	DynamoDB	....
AWS Step Functions	Kinesis Stream
AWS X-Ray	SNS

Dev Tools としての Cloud9 や Amplify、SAM、SAM CLIでのローカルテスト、Code Star、CodeCommit、CodeBuild、Code Deploy などの開発ツールも多く用意されている。

これに加えて、各種コミュニティのフレームワークがある。

Serverless とかあるけど、言語依存が厳しい.... Cloud Formation 嫌いだしやだなぁというのがおおい、このあたりはAzure Functions のほうが妥当感ある。Zipデプロイはかなりいいよね。

Use Case

アダストリア

WebAPI -> 新API Interface -> 旧API Interface -> API Server

Web API のこの流れは結構いいですね。開発上かなり柔軟になるし仕組みもシンプル。

Kinesis -> Lambda -> DynamoDB

ログやIoT でよく使われるやつ。

Web -> Stream -> Lambda -> DynamiDB/RDS/StepFunctions

こんなパターン

Lambda -> Lamnda (分類) -> S3 -> Lamnda -> RedShift
                           |                    
                         Athena

Firehorse 使っておけ感もあるけどね、

Firehorse -> S3 -> Lamnda -> RedShift
             |                    
           Athena

ライフサイクルマネージメント

• Console : Cloud9がLambda のコンソールに埋め込まれているので、手動で書くのもあり
• IDE : Eclipse/Visual Studio への統合
• Cloud9 (Cloud IDE) 上でテスト、デプロイまでできるので、まぁ便利
• コーティングを自分のエディタで + SAM CLI -> AWS Serverless Application Model

SAM CLI : ローカル環境にコンテナデプロいされてテストできるので、ローカルテストに便利。

基本的には、手動はCI/CDが厳しい。 そこで、他のツールでパイプラインを組むのがいい。

まぁ実際ね、そしてこのパイプラインがめんどくさいはめんどくさい。

パイプライン

よくあるAWSの流れでいくと、Code Pipeline でCode Commit -> Code Build -> AWS SAMあたりが繋がれる。

現場、AWSはテストサービスは(Device Farm以外)ないので、3rd party 使うしか無い。

Source	Build	Beta	Test	Prodiction
GitHub / CodeCommit	Code Build	Cloud Formation (AWS SAM)	3rd Party	Cloud Formation (AWS SAM)