tech.guitarrapc.cóm

Technical updates

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

AWS Serverless AWSLambda

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

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

他のセッション

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

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

目次

Title

What We Should All Worry About When Monitoring Serverless Applications

Speaker

Nitzan Shapira @nitzanshapira

Slide

[]

Complexity and Monitoring

Serverless は複雑.... Resource は管理したい、Application はどんどん複雑になっていく..... 管理不可能になる前に関しを...。

Function は大事 (貴重)

  • Out of Memory
  • Cold start
  • Timeout

でもみたいのは、Service ですよー。

System > Function

これは重要で、System は、Functions + APIs + Transactions なので、Function の集合がサービスではない。 Function だけでは不十分、かつ、非同期イベントの関しまでトラブルシュートと修正には必要になる。

Distributed Tracing

Micro Service は、ロジックが個別に構成されている。 ロジックは関連を知らないので、同様にどのように接続されているのかを把握する必要がある。

Jaeger で可視化できるが、必要なのはどうやってそのデータを得るのか。

Manual Traces/Instrurentaion

このあたりをつかってやったり...。

  • OpenTracing
  • OpenCensus

やらないといけないことは多い。

  • Before and after call

Serverelss apps are very distributed

Complex Systems have thousands of functions What about the developer velopcity?

Exisiing Solutions?

  • AWS Cloud WatchLogs : ログは見れるけどそこまで
  • AWS X-Rays : Distributed ではあるけど、Lambda まで、AWS Service のプロファイリングに過ぎない
    • いわゆる Distributed Tracing ではない
    • 非同期イベントもおえない

縦串に処理を負えない、中途半端なTracing、APMになっている。起因がなにかを判別するのが難しいのがとてもじゃないけど、コレでは足りない。

Quick Look が重要

Serverless でスピードアップするので、Developer体験もスピードアップが必要。 そのため、Quick Loock として、トランザクション全体のリソース間の処理時間がぱっと見えるなどのレベルで簡単さが重要になる。

では、マニュアルでCloudWatch Logs を Lamnda で5分毎にスキャンしてRDSへ?

* CloudWatch がHighly Throttleに
* Request が時間かかるように
* 5K 同時Lambda for 5min はむりぽよ。

当然コストもべらぼうに高くなる。

まったくで、この常時起動 + Fanout手法でのServerless は地獄一直線なぁ

Obervability

ということで、X-Ray もだめ、マニュアルも厳しいので Epasgon ですよ。

https://epsagon.com/

Dynamic Service Map ビジネスフローを乗っけている。

Transaction の流れ、があるのはかなりいいのでは。 グラフDB使わないと関連クムのだるそうだな

ログインはこっちから

https://dashboard.epsagon.com/login

まとめ

トランザクションの流れは注目したいと思いつつ、どうやるかアイディアがわかなかったのでいい感じに思う。けど、正直StackDriverでID関連で組めないかなぁっていうのもあり.... 処理ごとにってなると手間だけど地道にいくしかないかなぁ

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

AWS AWSLambda Serverless

毎年参加している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

AWS AWSLambda Serverless

毎年参加している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

資料

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

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

AWSLambda AWS Serverless

毎年参加している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

資料

導入するサービス

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

これまでの流れ

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

  • 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

AzureFunctions Azure Serverless

毎年参加している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