先週のAWS関連ブログ 〜1/10(水)

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

実に1年以上空いてしまったのですが、細かいキャッチアップとして大事なので久しぶりに書いてみます。

AWS公式

Meltdown and Spectre 脆弱性対応

年末年始から大騒ぎになっているMeltdown and Spectre脆弱性に対するパッチあて対応。Google Project Zeroおよび大学など複数の協力機関によってレポートされたIntel CPUに対する脆弱性ですが、以下のブログにあるようにクラウド各社は素早く対応しており、あらためてクラウドに乗ってて良かったな、という状況ですね。ホストOSへのパッチあてにより投機的実行が抑止されてパフォーマンス低下するという点については現在進行形で様々なユーザーからその性能測定結果などが出てきている状況ですが、ワークロードの特性によっても度合いが変わるようなので、自身の影響度合いについては自身で検証するしかないというが現実解ですね。

d.hatena.ne.jp

投機的実行の脆弱性によるパフォーマンスへの影響: CVE-2017-5754、CVE-2017-5753、および CVE-2017-5715 に対するセキュリティーパッチによるパフォーマンスへの影響 - Red Hat Customer Portal

プロセッサ予測実行研究の開示

上記の報告にあるとおり、AWSの仮想化基盤側はすでに対応を完了しており、ユーザー(ゲストVM)側の推奨アクションが示されています。


Amazon EC2

ECS最適化AMI

  • AMIは最新化済み 2017.09.e
  • 古い場合は sudo yum update kernel して再起動すること

Elastic Beanstalk

AWS Fargate

  • 対策済み、カスタマーによる対応不要

AWS Lambda

  • パッチ済み、カスタマーによる対応不要

Amazon FreeRTOS

  • 対策不要

RDS

  • RDS for MariaDB、RDS for MySQL、Aurora MySQL、およびRDS for Oracleはカスタマーによる対策は不要
  • RDS PostgreSQL と Aurora PostgreSQL もカスタマーによる対策は基本的に不要だが、plv8機能を使っている場合は専用のパッチを公開予定
  • RDS for SQL Serverはパッチを公開しているのでカスタマーが選択した時点で適用可能

VMware Cloud on AWS

WorkSpaces

  • 1/12以降にMSからセキュリティパッチを配布予定、再起動が必要
  • 独自のライセンスで独自の更新設定を入れている場合は自分でパッチ充て→再起動が必要

WorkSpaces Application Manager (WAM)


ところで上記RedHatのレポートもありますが、ワークロードの違いにより性能劣化の度合いに違いがあるのですが、AWSのサービスでいうとRDSとElastiCache、特にElastiCacheの劣化が個人的には結構痛いポイントです。まさに以下と同じような状況。

blog.orz.at

AWS Lambda および Tensorflow を使用してディープラーニングモデルをデプロイする方法

  • モデルの構築には莫大なリソースが必要だが、そのモデルを使った推論はサーバーレスで行うことができる
  • モデルはS3に配置したものをLambdaで読み込んで利用したり、サイズによってはコードのアーティファクトとともにパッケージして利用することができる
  • ただし依存ライブラリをすべてパッケージするためには一度EC2上で構築した環境から必要なものを抽出する必要がある点に注意する

aws.amazon.com

Amazon SageMaker でのご利用開始: より正確な時系列予測のための DeepAR アルゴリズム

  • Amazon SageMaker の最新内蔵アルゴリズムとして、Amazon SageMaker DeepAR がリリースされた
  • コールドスタート予測や確率予測の精度が高いと言われている

aws.amazon.com

Amazon EMR での Spark にバックアップされた Amazon SageMaker ノートブックの構築

  • SageMakerのプラットフォームにEMR Sparkを利用するための接続方法や、Livyを使ったSageMaker(Jupyter Notebook)と対話する方法について

aws.amazon.com

Building Connected Vehicle Solutions on the AWS Cloud

  • コネクテッドカー(ネットワークサービスと接続した自動車)に必要なAWSのサービス群を使ったパターンとその説明。
  • re:Inventで参加した自動運転カーのハッカソンでもこれらを活用して車から上がるテレメトリーをリアルタイムに可視化しました、非常に便利です。

aws.amazon.com

Build a notes app with React Native, AWS AppSync, and AWS Amplify

  • AWS AmplifyというAWSリソースにアクセスするためのJavaScriptと、ネイティブアプリを作成するフレームワークであるReact Nativeで、AppSyncを用いてGraphQLでデータアクセス・同期を行うノートアプリを作成する

https://aws.amazon.com/jp/blogs/mobile/build-a-notes-app-with-react-native-aws-appsync-and-aws-amplify/aws.amazon.com

AWS Direct Connectアップデート– 2017年後半に追加された新ロケーション10か所

  • 今まで東京のDXのロケーションを提供する事業者はEquinixしかなく、ラックが不足するとメトロコネクトなどでさらに張り出した先のデータセンターでコロケーションするしか選択肢がありませんでしたが、AT TOKYOもロケーションに追加された。
  • 日本で使うユーザーは東京のVPCと接続することが大半だが、国外のVPCと接続する場合は昨年発表されたAWS Direct Connect Gatewayが活用できる

aws.amazon.com

Combine Transactional and Analytical Data Using Amazon Aurora and Amazon Redshift

  • Auroraのデータの変更をLambdaでキャプチャし、Kinesis FirehoseでS3にデータを書き出し、RedshiftにデータをCOPYし、Spectrumで分析する仕組みの解説
  • WebアプリなどをOLTP処理し、別の情報系データベースで分析する需要は非常に多いため、サーバーレスで運用フリーかつニアリアルタイムに反映されるため便利

aws.amazon.com

AWS関連

サーバレスでスケーラブルかつ堅牢なシステムを構築するためのデザインパターンとアーキテクチャ。Serverlessconf Tokyo 2017

  • API Gatewayを主軸にしてAWSのサーバーレス構成のパターンについて話したServerlessconf Tokyo 2017でのDougal氏とPeterのトーク

www.publickey1.jp

Introducing the Amazon Alexa Premium Far-Field Voice Development Kit

  • ファーフィールド(広範囲)性能を備えたAVS対応デバイスを作成するための参照実装を公開した

Introducing the Amazon Alexa Premium Far-Field Voice Development Kit : Alexa Blogs

その他

遅い社会と早い個人のLearning to Learn

  • 産業構造の変化で人材が流動化するうえで社会や個々人がどのようにして新しいことを学び、変化していけばよいか。

objsbjvism.wordpress.com

2018年のサーバーレス

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

さて、前回の記事では今年のカンファレンスの開催報告をしました。今年もサーバーレス盛り上がりましたね。

yoshidashingo.hatenablog.com

トレンドをみると東京でカンファレンスを初開催した咋秋から、グローバルで4倍近いアテンションに高まっています。

さて、ここでは今年のサーバーレスの動きを振り返って頭の中をダンプしますんで、界隈の人と賛否両論なフィードバックをネタに年始の飲み会などができると嬉しいなと思っています。

1/24(水)に次回のServerless Meetup Tokyoを予定してますんでそちらはまた別途告知しますね。

エコシステムの発展

今年はエコシステムやマーケットが特に発達しました。

フレームワークツール

2015年にJAWS Frameworkから始まったServerless FrameworkはいまやGitHubで2万以上スターを獲得している超定番な開発フレームワークになりました。また、AWS SAMも順調に進化しています。

toris.io

※やっぱり読まずにスクロールしましたね。

サーバーレススタートアップ

また今年はIron Functionsの開発元であるIron.ioXenon Venturesを経由してOracleに売却されてそのプラットフォームに組み込まれたり、OpenFaaSが急激に頭角を現したりと、オープン系FaaSの話題が多かったです。

日本ではShifter*1GS2*2がさらに高機能化して日本のサーバーレススタートアップシーンを牽引してます。

また、海外からも複数のサービスが日本市場に入ってきました。Auth0*3Algolia*4Netlify*5あたりは日本オフィスを構えたり契約ユーザーが増えており順調な印象です。

コンサルタンシー/エージェンシー

クラウドプラットフォーム各社の上位ティアなパートナーの多く(cloudpack/クラスメソッド/サーバーワークス/スカイアーチネットワークスなど)がサーバーレスを活用した開発を請け負う専門部署を運営し始めたのも今年でした。サーバーレスのメリットを享受しながらある程度リスクオフしたいユーザーにとってこれは新たな選択肢です。

プラットフォーム

また、今年後半はクラウド各社のサーバーレスなプロダクトが充実してきたことで「サーバーレスとは何か」という定義についてあらためて考える場面が多かったです。「サーバー管理不要」「スケーラビリティ」「使ったぶんだけ課金」の3つの特徴だけが「サーバーレスコンピューティング」の特徴と言い切れなくなりました。

AWS

aws.amazon.com

Microsoft

azure.microsoft.com

Google

cloud.google.com

サーバーレスコンピューティング = プロキシ + 実行環境 + ステート管理 = リアクティブなマイクロサービス

サービスの充実を受けてあらためてサーバーレスの特徴を考えてみて、リクエストのプロキシ実行環境ステート管理(ステートマシンやワークフローのオーケストレーション、さらにはエラー管理やリトライ処理)が分離されて管理できることがサーバーレスの最大の特徴だと確信しています。プロキシと実行環境の分離がスケール管理不要や実行時のみリソース調達&課金といったクラウド事業者が共通して宣伝してる部分であり、実行環境とステート管理の分離が開発生産性やアプリのロバスト性につながるアプリの実装で意識すべき部分かなと思います。

システムの処理パターンとコンポーネントの組み合わせをちょっと見てみましょう。

3つの基本的な処理パターン

  • Webプロセッシング
  • ストリームプロセッシング
  • バッチプロセッシング

各コンポーネントの説明

  • リクエストプロキシ
    • WebアプリにおけるリクエストプロキシはNginxなどのプロキシサーバーやREST APIの場合はAPI Gatewayがこれにあたりますが、ここがサーバーレスにおいてはプラットフォームの提供するAPI GatewayやFaaSのHTTPトリガによってリクエストを受け付け、トラフィックルーティング、キャッシュ管理、保守不要、無限のスケール、流量管理などをしたうえでバックエンドにルートします。オープン系FaaSではこのトリガ(HTTPトリガ含む)はアプリのエンドポイントのプロキシコンテナが実行環境のコンテナとは別に常時起動しているという仕組みになっています。
    • ストリームであればKinesis StreamsEvent HubsCloud Pub/Subがこれにあたり、Publisher(Producer)がストリームに対してデータを投げ、Subscriber(Consumer)がデータを取り出して処理を行います。
    • マイクロバッチであれば、SNSEvent Gridのような非同期かつプッシュ型のプロキシもあれば、非同期かつPull型のSQSCloud Pub/Subといったキューがこれにあたります。
  • 実行環境
  • ステート管理
    • Webアプリではステートマシンを使うことはないですが、エラー処理やリトライ制御が実行環境と切り離されていることがロバスト性を担保する鍵になります。Lambdaであれば同期イベントのエラー時にはHTTP429が返却されるため、エラー処理はクライアント側での実装になるという意味で切り離されています。
    • マイクロバッチにおけるステート管理はStep FunctionsDurable Functionsのように複合条件やファンアウトの待ち合わせを行うステートマシンや、ジョブネットのような実行順序制御を管理するオーケストレーションから、Lambdaの非同期ジョブの自動リトライや、デッドレターキュー(DLQ)によるエラー制御の外部定義などです。これらを活用することで、こういった制御をロジックレイヤーから切り出すことができることで、コードに依存しないアプリのロバスト性やメンテナンス性を確保することができるようになります。おそらく今後サーバーレスの開発生産性を議論する場合にはこういったソフトウェアエクセレンスを考える必要が重要になってくるでしょう(※単純にマネージドサービスを使って「作らない部分を増やす」だけでなく、「作る部分をどれだけ小さく/正しい粒度に保てるか」といった観点や、Testableであるという観点)

アプリケーション共有リポジトリ

生産性について言うと、今年はAWS Serverless Application Repositoryのようにアプリケーションを定義化して共有できるサービスも増えました。これは当初Serverless Platformが似たような構想として始まっていましたが、AWSはSAMをベースにこれを実現し、StdLibではそれぞれリクエストのIFや実装方法が違うFaaSのコードを共通化しておいて、各プラットフォームに合うように変換してデプロイできるレポジトリサービスを開始しました。

認証サービス

従来モノリシックなサービスであれば、アイソレートされたサーバーの内側での通信や保護されたネットワーク内部の通信で良かったものの、マイクロサービスのようなドメインをまたいだサービスの呼び出しなどが必要な場合、ネットワークによる保護以外の方法で安全に呼び出し会える必要があります。

リクエスト時に認証された一時トークンを引き回すためにOAuth2などに対応したAuth0のようなサービスや各クラウドプロバイダーのマネージドサービスがサーバーレスなマイクロサービスを作る上でのキモになります。

いろんなニューカマー

4つのサーバーレスカンファレンス勢

今年はServerlessconfや元々Serverlessconfを始めたメンバーによって立ち上げられたJeffConfがより運営をフランチャイズ化して発展しました。それにくわえて、Serverless, inc. 主催のemitが初開催され、ServerlessconfやJeffConfよりもより対話・議論を重視した内容で盛り上がりました。

また、インドではServerless Summitというこれら3者とはまったく別のイベントがOracleをリードスポンサーとして初開催されました。

Oracle Cloud

そのOracleですが、買収したIron.io自体は既存事業を維持しつつもOracle Cloud上での展開も見据えてIron Functionsとは違った新しいFaaSのプロジェクトであるFn Projectを提供し始めました。先行きに関してはまだ不透明ですが、来年はさらなる台頭が期待されます。特にIronFunctionsはただのオープン系FaaSというだけでなく、自社で提供しているIronMQなどと連携ができることを売りにしていたので、Oracle Cloud内の各種サービスや、人事や会計のSaaSパッケージとの統合が進むと有益なユースケースが多いのではないかと考えています。

とはいえ、少なくとも日本においてはクラウド事業のプレゼンスがほぼゼロに近いオラクルが、まだ儲かりそうにないサーバーレス分野において継続的に積極投資ができるかどうかは未知数ですね。

さらに来年はAlibaba Cloudのクラウドマーケットでのプレゼンスがさらに高まります。彼らはすでに中国国内(かつ中国アカウント)のみで利用できるFunction ComputeというLambdaに似たFaaSを提供しています。

FaaSはバインドサポートの多さがあってこそとあらためて思った

ただしこのFunction Compute、現状OSS(オブジェクトストレージ)のオブジェクト作成のトリガしかサポートされていないため、画像のサムネイル作成や圧縮ファイルをほどくようなユースケースしかないなと感じたのが正直なところで、あらためて「FaaSは周辺サービスとのネイティブなバインドサポートがどれだけ充実しているか」によって開発生産性が大きく変わりそうだなと感じました。

ロジックレイヤーだけあっても、上記で書いたようなプロキシ(Enent Grid機能)とステート管理レイヤーが充実しないとサーバーレスなシステムを作るベネフィットは得られにくいなという感想です。

Alibaba Cloud

そのAlibaba Cloudですが、上記のFunction Compute以外にもk8sベースのContainer Serviceもあったり、ビッグデータ系のサービスも充実しており、モダンなクラウドサービスで当然提供されているべきマネージドサービスが一通り揃っています。

先日Container ServiceのPMと会話したところ、Alibaba.comはすでにすべての基盤をこのContainer Service上で展開したうえで先日のダブルイレブン(11月11日、通称独身の日)の注文を捌いたらしいです。またSwarmモードしかなかったリソーススケジューラーもKubernetesモードの展開を進めていくので、特定のユースケースを除けばKubernetesモードがデフォルトになっていくだろうとのことでした。

来年はさらにグローバルなマーケットを相手にしてる会社ほど、中国の内需を取り込むことを想定してはじめから基盤をAlibaba上でという選択が増えていくと思います。ICPライセンスの申請しやすさや、ビジネス慣習にあった業務提携が得られるというのもメリットだと思います。

ちなみに準拠法については日本で契約したアカウントは日本に準拠します。とはいえ地政学的リスクとして中国のクラウドプロバイダーの姿勢はちょっとなーということも実際あるので、ユーザー自身の情報の開示は仕方ないにせよ、保存されるカスタマーのデータはクライアントサイド暗号化で保護すべきで、そこらへんはまた別途の機会に真剣に考えてみましょう。

今後

とりとめなく書き出していったわけですが、プラットフォームについてはより群雄割拠になっていくと想定されますが、RedHatがFunktionの支援をやめたり、それなりにドロップアウトもあるんで、来年はもっとトピックが増えるでしょうね。

日本のサーバーレスシーンでは、もっとエンタープライズアーキテクチャやデザインパターンなどを背景にした実装方法の議論が出てくるべきです。この点はカンファレンスやMeetupのオーガナイザーをやってる自分としてもある種使命感のようなものを感じています。

さらに来年のServerlessconf Tokyoは、ワークショップやセッションだけでなく、サーバーレススタートアップのピッチとか、ハッカソンなどを企画したいと思っています。

来年はサーバーレスについてもっと皆さんと議論して、マーケット自体がもっと大きくなってくれると嬉しいです。それでは。

*1:ShifterはテンポラリのWordPressコンテナ(プラグインなども利用可能)を使って記事を静的なページにパブリッシュしてCDNから配信することで、スケーラビリティを気にせず安定運用できるサーバーレスなWordPressホスティングサービス

*2:ゲームに必要な検索やランキングといった部品をSaaSとして安くスケーラブルに安定的に提供するAWSやGCPのサーバーレスコンポーネントで作られているサービス

*3:システムに素早く組み込めて安定している認証サービス。Extendではそれに加えてWebtaskという実行レイテンシの安定したFaaSが使える。Auth0自体もこのWebtask上に実行環境が載っている

*4:爆速検索サービス、インクリメンタルサーチも爆速ならインデックス更新も爆速

*5:静的サイトの配信サービス。ただS3ホスティングやCDNを使うのとは異なり、SSRなどが可能

Serverlessconf Tokyo 2017 開催報告

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

2017/11/2-3の2日間にわたり今年もServerlessconf Tokyo 2017を開催したのですが、まとめた数字やフィードバックなどを共有してませんでしたので、簡単に共有して開催報告といたします。

IMG_6427

イベントの"数字"

  • チケット登録者数 Total Tickets: 463名

IMG_5846

2017/11/2(Thu) Workshop

  • 5つのオリジナル・ワークショップ
    • Serverless Tech Challenge with AWS Serverless Services (AWS provided)
    • Create A Trainable Bot as a Service with Azure Functions and Logic Apps (Microsoft provided)
    • Build your own serverless video sharing website with Lambda, API Gateway and Firebase (A Cloud Guru & Serverless Community(JP) members provided)
    • Develop a Serverless Weatherbot with IBM Cloud Functions, Apache OpenWhisk and the Serverless Framework (IBM provided)
    • Introducing a new event-driven world with Serverless Framework (Serverless Community(JP) members provided)
  • 参加者 Attendees: 95名

IMG_5657 DSC_9341 IMG_5601

2017/11/3(Fri) Conference

  • 講演 Sessions: 21本 + LT 6本
  • 参加者 Attendees: 379名

IMG_5986 IMG_5896 IMG_5886 IMG_6051 IMG_6061 IMG_6241 IMG_6219 IMG_5963 IMG_6288

アンケート結果 Summary of Survey

2017/11/2(Thu) Workshop

  • 有効回答数 Numbers:54
  • 全体満足度 Totally Satisfaction:4.40 (以降すべて5段階)
  • 難易度 Difficulty:3.33
  • 時間の長さ Length:3
  • スタッフのサポート Support:4.3
  • 会場 The Venue:4.44

2017/11/3(Fri) Conference

  • 有効回答数 Numbers:129
  • 全体満足度 Totally Satisfaction:4.52
  • セッション・スピーカー Speakers:4.45
  • 会場 The Venue:3.86
  • スタッフ Staff:4.48
  • 食事 Meal:3.99
  • イベントは自身の期待に答えたか:4.48
  • このイベントを友人知人に勧めたい(これのみ10段階):8.65

その他フィードバック Feedback

個々のアンケート回答にしてもソーシャルメディア上の反応でも、ワークショップやセッションの中身には特に満足度が高い結果になっており、スピーカーの皆さんには大変感謝しています。

f:id:yoshidashingo:20171213181753j:plain

■ Twitterまとめ togetter.com

スポンサー各社からは、非常に高いブースへの立ち寄り/アンケート回収など得られて費用対効果が高かったというフィードバックを多数もらいました。個人的に見ていた範囲でもどのブースも途切れることなく参加者と情報交換がされていたという印象でした。

IMG_5826

また、個々のアンケート回答やスタッフ全員でのKPTふりかえり作業を経て、タイムラインの編成や受付スタッフの教育、英語での案内の少なさといった課題は残ったので、次回に向けてまた頑張ろうと思っています。

写真

今回も素敵な写真たちが仕上がってます、中井さん、加我さん、森田さん、ありがとうございました。文章中にもこちらから選定して掲載させていただきました。

■ Serverlessconf Tokyo 写真集

Flickr: The Serverlessconf Tokyo 2017 Pool

プレゼン資料

■ Keynote: Software Productivity and Serverless IMG_5855

www.slideshare.net

■ Keynote: Growing up Serverless IMG_5932

www.slideshare.net

■ Retrofitting your Monolith with Serverless and Design Thinking IMG_6079 speakerdeck.com

■ 真のサーバレスアーキテクトとサーバレス時代のゲーム開発・運用 DSC_9790 speakerdeck.com

■ Step FunctionsとAWS Batchでオーケストレートするイベントドリブンな機械学習基盤 DSC_9766

www.slideshare.net

■ Biz Serverless お客様のビジネスを支えるサーバーレスアーキテクチャーと開発としてのビジネスの課題 IMG_6253

www.slideshare.net

■ Serverless on Google Cloud Platform IMG_6189 https://speakerdeck.com/urasoko/serverless-on-google-cloud-platformspeakerdeck.com

■ サーバーレスについて語るときに僕の語ること IMG_5975 speakerdeck.com

■ Continous Delivery Strategy for Serverless world IMG_6020

■ Open source application and Ecosystem on Serverless Framework IMG_6235 speakerdeck.com

■ APIからFirebase Realtime Databaseへ - クライアントサイドから見るサーバーレスアーキテクチャー IMG_6278 speakerdeck.com

■ The mind of Serverless as a Software - Serverlessの世界に特別なことなんて何もなかった DSC_9792

■ サーバレスアーキテクチャによる時系列データベースの構築と監視 DSC_9731 speakerdeck.com

■ Java チームが選択した TypeScript による AWS Lambda 開発 IMG_6099 riotz.works

■ BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 IMG_6173

www.slideshare.net

LT資料

■ Serverlessとか言う前に知ってほしいDBのこと DSC_9931

■ FaaSで簡単に実現する数十万RPSスパイク負荷試験 IMG_6352

www.slideshare.net

■ OpenSource with Serverless World DSC_9908 speakerdeck.com

■ now IMG_6334

www.slideshare.net

■ 「サーバレスの薄い本」からの1年 DSC_9893

www.slideshare.net

■ イミュータブルなDB設計とサーバーレス IMG_6306

ということで来年もスタッフの皆さん、スピーカーとして話してみたい方々、スポンサー各社の皆さん、よろしくお願いします。