Serverlessconf Parisに行ってObservabilityについて考えた

セクションナイン吉田真吾@yoshidashingo)です。

2018.2.14,15の2日間、パリで開催されたServerlessconf Parisに参加してきました。今回のパリ開催は東京を私がオーガナイズしているのと同様、D2SIというパリのコンサルタンシーが行うフランチャイズ形式で行われました。

paris.serverlessconf.io

Togetterまとめ

togetter.com

Observavility

f:id:yoshidashingo:20180215091930j:plain

1本目はヤンさんのObservavility に関するトラックでした。Observavilityはマイクロサービス界隈を中心に重要なトピックになっており、さらにサーバーレス界隈でも、複雑化するピタゴラスイッチを分散トレーシングするサービスやツールが増えてきてることから注目度が上がっているため興味深い内容でした。 昨年、東京のカンファレンスにも参加してくれた Espagon や、DataDog らもブースを構えておりプロモーションを頑張っていました。

www.slideshare.net

blog.d2-si.fr

Observabilityについて書かれた記事の初出はこのTwitterの記事あたりでしょうか。Twitterをモノリシックから分散アーキテクチャに変更したことで、システム間の複雑性が上がったため、複数のサービスにまたがる処理において発生した問題の原因箇所の特定のための可視性の担保が重要だったという話で、実際にどうメトリクスを収集したか、可視化したか、モニタリングしてアラートしたかといった内容が書かれています。

blog.twitter.com

2013年に続き2016年にも。

blog.twitter.com

時は流れてマイクロサービスアーキテクチャが普及してきた昨今、単一システムごとのメトリックをダッシュボードに並べてもシステム全体が見えないモニタリングのしにくさ、障害検知したすべてのノードからのアラート地獄、分散環境内での根本原因箇所の特定の難しさ、セントラライズされずに散らかったログなど、モノリシックなシステムにはなかった課題を解決する必要があり、まさにObservabilityが課題となっておりますが、当初はMonitoringの文脈の上位概念だったObservabilityが、これらの課題を解決するための「モニタリング」「スマートなアラート、ダッシュボード」「分散環境上でのトレーサビリティ、障害検知」「ログ収集、分析」といった、オペレーションに必要なすべての要素の上位概念として最近では位置付けられているみたいです。

  • Monitoring
  • Alerting/visualization
  • Distributed systems tracing infrastructure
  • Log aggregation/analytics

medium.com

OSSの分散トレーシングツールもちまたにたくさんあります。

github.com github.com github.com

さて、サーバーレスで構築されたマイクロサービスにおいては、サービス間のトラフィックモニターや、障害箇所の特定のしやすい可視化ダッシュボードや、スマートなアラートシステム以外に、FaaS独特の課題を解決するためのトレースも必要になります。たとえば、Lambdaのイベント連携のトレースができる AWS X-Ray などもそうですが、現在X-Rayは非同期呼び出しの場合の連携先まではトレースされません。Espagonなどはこれらに対応してると口頭で聞いてますが、どうやってるかなどは企業秘密だそうで、いずれにしても「サーバーレス」で「非同期」な「分散環境」をトレースする方法は、システムをどう可視化して保守したいかによって、複数の選択肢の中から組み合わせて実現するのが現在のベストプラクティスみたいです。

※いちおこんなやり方はできそう↓ qiita.com

ということで Charity Majors さんもこんな感じで語っているとおり、サーバーレスな分散システムには、そのシステムのアーキテクチャ自体がモノリシックから大幅に流儀の違う形に変更したように、モニタリングやトレース、ロギングについても大幅なアップデートを行い、Observabilityを確保する必要がありますね。

blog.intercom.com

speakerdeck.com

CNCFのホワイトペーパー

f:id:yoshidashingo:20180215121240j:plain

また、CNCFのServerless WGから発行されたホワイトペーパーについての話も前評判の割には面白かったです。内容について歯切れは悪いですが網羅的に今までのサーバーレスの話題が記載されてはいるかなと(斜め読みしかしてませんが)。ただし、海外ではサーバーレス界隈の人の間ではまったく話題になってません。なんでだろうなと思ったんですが、おそらくもうここ周辺の話題(定義とか歴史的経緯とか)に完全に食傷気味なのと、CNCFの標準化に向けたイニシアティブをどう扱ったらいいものか対応し兼ねてるということなのかなと。たしかにもう2年やってますからね、こういう話。

github.com

www.publickey1.jp

Accelerating DevOps with Serverless

俺らの@ijinさん。

f:id:yoshidashingo:20180215121831j:plain

youtu.be

その他

Randallがライブコーディングしたり、nuclioが結構インテリジェントエッジの部分にフォーカスして十分なソリューションになっていたり、RyanがSpaceXとサーバーレスの小話で最後〆てたり、結構面白かったです。

blog.d2-si.fr

次回開催のことなど

  • 次回は5月に「BINARIS」が運営母体で「テルアビブ(イスラエル)」で開催されるそうです。
  • 東京も今年も9月か10月に開催予定です。準備頑張ります。

パリについてのメモとか

  • 今回は滞在が24時間以内ということで、エッフェル塔も凱旋門も回れずでした。6月あたりが最高のシーズンらしいので、また6月に来てシェイクスピアアンドカンパニーとかちゃんと観光で寄ってみようと思います。
  • カンファレンス会場であるEspace Saint Martinと同じブロックにある レバンパリ という、ニューヨークのAce Hotelを2段階くらい高級にした感じのホテルに泊まったのですが、設備はAce Hotelそっくりで派手ではないのですが、シャンプー、石鹸、コロンにいたるまで最高に自分に合うもので、またパリに行く機会があれば毎回あそこがいいなと思うくらい良かったです。もし行く人がいれば参考にしてください。
  • メシは何を食べても美味かった。
  • Amex使えないところ多かった。

Nuit à Paris

Alexa Day 2018でVUXデザイナーやカスタムスキルのつくりかたの話をしてきた #alexaday2018 #jawsug

セクションナイン吉田真吾@yoshidashingo)です。

2/11(日)に開催されたAlexa Day 2018でVUXデザイナーのことやサーバーレスの話、Lambdaで対話モデルを実装する方法などについて話をしてきました。

f:id:yoshidashingo:20180211160141j:plain

www.slideshare.net

今年に入ってからカスタムスキルをデモする機会が増えており、ちょうどいいタイミングでした。実装方法の説明についてはエコちっちのデモをベースにしました。

↓↓↓デモが失敗した場合に備えて前室で録画しておいたもの↓↓↓

youtu.be

1つだけポイントを挙げるとすれば「ステート」です。動画の中で3回エコちっちのコマンドを実行してますが、1回目は初期化、2回目はコマンド指示、3回目は状態確認コマンドからのコマンド指示であることです。これを実現するために必要なのが「ステート」です。

エコちっちとの対話は比較的単純なほうですが、このレベルでさえ心地よい対話フローを実現するためにはそれなりに事前に対話フローの設計が必要で、うちでもVUXデザイナーを育て始めています。新しい職業が生まれてるわけですからね。とてもエキサイティングな瞬間だなと感じてます。

あと、こんな感じでGUIで定義するフローからデプロイできるようなツールがあるといいなと考えています。

また、懇親会ではDJさせていただきました。djay + Beatpad、優秀。

f:id:yoshidashingo:20180211184628j:plain

※金春さん、写真ありがとうございました。

先週のAWS関連ブログ 〜1/21(日)

セクションナイン吉田真吾@yoshidashingo)です。

AWS公式

Amazon RDS for MySQLとMariaDBのログをAmazon CloudWatchで監視出来るようになりました

  • General query log(発行されたSQLやクライアントの接続時間など)、Error log、スロークエリ、AuditログをCloudWatch Logsのロググループに自動的に収集することができる。
  • 収集したログはS3にエクスポートしたり、LambdaやElasticsearch Serviceにサブスクライブさせて後続の処理(ESへの取り込みやLambdaで何かの処理を実装)することが可能

aws.amazon.com

たとえば、定期的に監視サーバーから上記のログをさらってESに入れたり、エラー行を見つけたらアラートを送信していたような処理は管理系サーバーなしにリアクティブな仕組みで可視化することが可能になる。

AWS Auto Scaling

今までAuto Scaling可能だった複数の機能がひとつのダッシュボードで管理可能になった。

aws.amazon.com

LambdaがGo言語とC#(.NET Core 2.0)をサポート追加

AWS Lambda での Go サポート開始

AWS Lambda での C# (.NET Core 2.0) サポート開始

AWS FinTech リファレンス・アーキテクチャー日本版の公開について

日本の金融機関やFinTech業者がAWSを利用する際によく参照する要求事項を整理し、CloudFormationテンプレートにして公開した。

特集ページFINTECH - アマゾン ウェブ サービス (AWS)

aws.amazon.com

SageMakerのアップデート

  • モデルのトレーニングと推論処理のホスティングに利用するストレージをKMSで暗号化可能に。
  • Word2Vecの最速実装であるBlazingTextを複数のCPUやGPUで並列化して処理する。すぐに試せるノートブックのサンプルはこちら
  • アクティビティをCloudTrailで記録可能になった。

aws.amazon.com

aws.amazon.com

aws.amazon.com

Gunosyさんの記事配信をKinesisで最適化した話

aws.amazon.com

AWSもブロックチェーンやってるってよ

  • ブロックチェーンパートナーのソリューションを利用してAWS上でブロックチェーンのシステムを作りましょうという話

aws.amazon.com

AWS DMS と Amazon Kinesis Data Firehose を利用した Aurora PostgreSQL データベースへのストリームデータのロード

  • ストリームデータをAurora PostgreSQLにETLするパイプラインの作成方法
  • 間でLambdaでファイル形式の変換やデータ形式の変換をしながらロードすることでリアクティブで自動化されたパイプラインができる

aws.amazon.com

機械学習と BI サービスを使用してソーシャルメディアダッシュボードを構築する

  • Firehoseに受け取るTwitterのストリームデータをLambdaに発火してAmazon TranslateとAmazon Comprehendで自然言語解析処理して書き戻したS3上のデータに対して、QuickSightからAthenaでクエリさせることでダッシュボードに表現する
  • Amazon Translate/Comprehendを用いることで、地域ごとに言語が違うことを吸収して分析と地図などへのプロットができる。

aws.amazon.com

Microsoft Excel を使った Amazon Lex チャットボットの構築

  • AWS コミュニティヒーローである Cyrus Wong (香港専業教育学院のデータサイエンティスト)と学生4人による成果発表。
  • Excelに必要事項を埋めてアップロードするとAmazon Lexを使ったチャットボットが構築できるという実践例
  • ExcelをS3にアップロードし、発火したLambdaでExcelを分析してSAMテンプレに置き換えて、デプロイする。

aws.amazon.com

"ベンダーロックイン"という都市伝説をぶっ倒せ

クラウド業界にはいくつかの金科玉条のような都市伝説があります。一般的には「クラウドよりオンプレのほうが安全だ」「クラウドは信頼性が低い」そして、「ベンダーロックインされる」といったあたりです。

いまやあらゆる仮想ホスト基盤のパッチが素早くオンラインで適用されていき、セキュリティ基準やガバナンスレポートも網羅しており、仮想ホスト基盤より下の安全性については完全にクラウドの勝利です。信頼性についてはアーキテクチャで担保するのが当たり前になりましたし、そもそもクラウド上のサーバー運用保守をやっていると毎年のように仮想サーバーが単体でわけのわからないダンマリ状態に陥ったり、ノイジーネイバーの影響を受けるようなことが皆無になってきました。

そしてベンダーロックインについても、「組織の意思決定の遅さや成熟度が低いことによる」ロックイン以外は存在しないということがすでに明らかです。ということでくだんの記事。

aws.amazon.com

  • 長期契約が必要ない:利用分のみに課金されるように設計されており、好きなテクノロジーを持ち込み、必要なくなればVMをエクスポートしたりして別に移ることも容易に可能である。
  • 顧客が技術選択可能:プロプライエタリなツールを代替する業界標準なソリューションをサービスとして多数展開しているので、アプリケーションをそういった業界標準で可汎性の高いソリューションに合わせて移植することができる。
  • 乗りやすい、出て行きやすい:移入/移出いずれについてもサポートするツールやドキュメントが用意されている。たとえばSQL、LinuxやXenといったオープンスタンダードな技術でできているので、クラウド間やクラウドとデータセンター間のサーバーやデータの移動がしやすくなっている。

アプリケーションの移植には基盤の移行より何倍ものコストがかかるため、どこにアプリケーションを配備していても移行に想定以上にコストがかかるというのはよくある話であること。また、自社で数十万VMや数PBレベルのストレージを運営している場合であれば専門組織を抱えてより高いコスト効果を目指すというのも当然アリだが、それはすべてAWSに移行してしまうというよりそもそも何倍も大変であるという点には留意したいですね。

その他

Amazon Web Services 業務システム設計・移行ガイド 一番大切な知識と技術が身につく

出版されたそうです。AWSで業務システムを設計・構築する方は買って読みましょう。