tech.guitarrapc.cóm

C#, PowerShell, Swift, Cloud, Serverless Technical Update and Features

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

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

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回目になります。

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)

はてなブログの予約投稿でTwitter投稿をするとFacebookにも投稿されるようにIFTTTを設定する

予約投稿時のFacebookに同時にシェアする機能が廃止されるようです。

f:id:guitarrapc_tech:20180722190948p:plain

staff.hatenablog.com

やりたいことはようは、予約投稿に合わせて自動的にFacebookにも投げられればいいので、IFTTTを使って自動化してみましょう。

前提として、Twitterには投稿しているものとします。

続きを読む