ServerlessDays Tokyo 2019 å‚åŠ ãƒ¡ãƒ¢

ServerlessDays Tokyo 2019の参加メモです。
参加する前はセッションが選べないので微妙とか思ってましたが、実際参加すると普段触れない話(※主にAzure)が色々聞けたので良かったです。昼からの参加となったのが残念でした。。お昼ご飯には間に合いました。おいしかったです！（小並

â– ServerlessDays Tokyo 2019
tokyo.serverlessdays.io

スライドなどは「#ServerlessDays」から大体追えると思います。
twitter.com

以下セッションのメモです。

â– All You Need Is JavaScript
・CloudFlareの中の人が日本語で発表されていた。
・TypeScriptはJavaScriptに追いつきつつある。
・CloudFlareはCDNサービスやセキュリティサービスなどを提供する事業者。
→Akamai的な企業。
https://ja.wikipedia.org/wiki/Cloudflare

â– Zero Scale Abstraction in Knative Serving
・Knative
→k8sをサーバレスで動かすためのワークロード
https://cloud.google.com/knative/?hl=ja
・Herokuと似たプラットフォーム
→k8sの上に拡張している。
・「k8sをクラウド上で抽象化したサービス」
・yaml地獄にならない。knative側でコード化可能 。
・GoLangで書かれている
・kubectlなどのk8sのCLIを利用するのではなく、
　Git上でKnativeの構成管理を実施する。「GitOps」。　
　→「push code, not container」
https://thinkit.co.jp/article/14164
・podに同梱できるコンテナは１つだけ。（sidecarなどはできない）
・ボリュームのアタッチができない
→理念にそぐわない
・podをどのインスタンスで立てるかを指定できない
→理念にそぐわない
・オートスケール未対応。ヘッダ毎の振り分け未対応。
・Cyberで利用検討中。k8sを直接利用するのは敷居が高い。
→GCPではサービス提供されているが、AWS上でKnative立てようとしている。
・KnativeのバージョンアップはAWSのGlobal Acceleratorを利用しようとしている。

■ 空調設備向けIoTシステムにおけるクラウドランニングコスト
・コスト削減のお話。AWS DynamoDBの中心に紹介
・30万人が利用するIoTシステム
→サーバレスが必須
https://aws.amazon.com/jp/solutions/case-studies/daikin/
・サーバレス開発は勉強工ストとの闘い
・空調機→kinesis→DynamoDB
⇒遠隔操作が必要な機器のデータを格納
⇒運転データサイズ（最大で数１０ｋｂ）が飛んでくる
・1回のAPIコールで数十個の機器データを取得する使い方をする
・Lambdaの処理時間とDynamoDBのDPUがコストの大半を占めるようになった。
・DynamoDBの課金仕様を踏まえ、アイテムを分割した。
⇒書き換える対象のデータ容量を小さくした。
・一括更新するようなクエリがある場合はインデックスを追加して一括更新できるようにした。
⇒処理時間の短縮によるLambda処理時間の短縮
・DynamoDBのキー構造が重要（性能・コスト）

・コストの失敗
⇒インスタンス起動しっぱなし
　→負荷ツールもサーバレスで作る方がよい
⇒ログ多すぎ問題
　→CloudWatch Logsのコストが高い

■ ISPがサーバレスに手を出した
・OCNの中の人
・PPPoE混みすぎ問題(IPv4)
⇒VirtualConncect(IPv6) /56を提供する。
・v4 over v6 tunnel
⇒お客様側機器に対してIPv6接続を要求する必要がある。
・社内基準と電通法対応
⇒たまたま自社クラウドがIPv4対応していなかった。仕方ないのでIPv6で対応
⇒回線数に応じて信頼性を担保する必要がある。（※総務省への報告が発生するらしい）
⇒AWS（クラウド）が本当に信頼に足るか、という調査をした。
・Azure CDN
⇒common nameが指定できない（設定が消える？？）
⇒AWSへ乗り換えた。DynamoDB GlobalTable利用。
・テスト自動化
⇒ServerlessFramework（ローカルでも動かしたい）
　→プラグインのアップデートが早い
　→細かいところは非対応のところがある（CDN系とかの設定項目など）
⇒gatlingという負荷ツールを使っている
https://qiita.com/ntrv/items/394a38d26e94565db31a
⇒負荷をかけるとユニットの切り替え・追加のタイミングがみられるのでためになった。

・B-Gデプロイの方法で悩んだ（CDNで切り替えた）
・CloudWatchフル活用。
⇒Cloudwatch LogInsightsでエラー分析をやっている。CloudWatchを直接覗くのはまれ。
・標準化も今後やっていきたい
・人間がボトルネックになっている（２人しかいないので…とのこと）

■AWS Lake Formation で実現、マイクロサービスのサーバーレスな分散トレーシング
・複雑に絡んだサービスのエラー調査を分散トレーシングで解決する話
・step functionsを利用したログの出力
・トレーシングID
⇒X-Rayは非同期処理に対応できないのでトレースIDの取り回しが必要。
　→APIGW(HTTPヘッダ)⇒SNS（構造化メタデータを設定）⇒SQS（MessageAttribute）
　 ⇒STEP Fn(ResultPathを利用)⇒S3(Object metadata)

■Don’t think Serverless Security, think Application Security
・イスラエルのスタートアップ企業の方（Nuweba）。全編英語だったので間違っているかも。。
https://www.nuweba.com/
・サーバレスセキュリティ。
https://www.nuweba.com/dont-think-serverless-security-think-application-security

・new cyber security risks
１．attack（trigger, event）
⇒攻撃対象の多様化。例えばAPIGW,Lambda,IoTなど。
２．harder to manage
⇒サーバレスなプラットフォームの場合、攻撃に気づくのが難しい
３．denial of wallet
⇒リソースの過剰消費攻撃
https://www.helpnetsecurity.com/2019/03/29/serverless-challenges/
４．Serverless leads to over-privilleged functions IAM permissions
⇒認可と認証の対象、範囲を適切に管理する必要がある
５．（サーバレスであっても）コードの脆弱性は混入する恐れがある（？）

■Azure でサーバーレス、 Infrastructure as Code どうしてますか？
・IaCの話。
・クラウドにおけるリソース管理
⇒ARM(Azure Resource Manager)テンプレート。JSON。
・VSCodeだとシンタックスが効きます。
・AzureのGUI上で内容確認可能
・Azureだとアップロードしたzipの中のファンクションを指定して実行可能。
⇒デプロイ後にすぐ実行が可能
・https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-infrastructure-as-code
・リソース名のつけ方に注意（制約がある。24文字以内）
・IaC：CI/CDの活用が捗る、新規参画者にやさしい

â–  The hidden cost and technical debt of running huge Serverless service on production
・本番環境で巨大なコンテナワークロードを実行したときの課題
・1TB位のEBSに障害が起きたら、特定のフレームワークしか使えませんなど
・サービスを最新の状態に保つ必要がある
・利用サービスの継続的な見直しが必要。
⇒AWS Simple WorkflowではなくStepFunctionを使うetc
・手動プロビジョニング
・データベースのプロビジョニング
・ベンダーロックイン
⇒ベンダーフリーにすることは難しい
・請求管理を集約することで管理が容易になる
・ベンダーを統一することはコスト面で有利