ServerlessConf Tokyoではスピーカーとスポンサーを募集しています

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

今年5月にNY、ブルックリンで開催されたServerlessConf NYCから約2ヶ月。2箇所目として「東京」が9/30&10/1、3箇所目として「ロンドン」が10/26-28に開催されることが発表され、サーバーレスの勢いはますます増しています。

tokyo.serverlessconf.io

東京開催についてセクションナインが担当することになりましたが、NYCで話したスピーカーやスポンサーも決まっており、もう少ししたら詳細の発表やチケット販売を開始できるようになると思います。お待たせしてすいません。

Serverlessとは?

サーバーレスはクラウドコンピューティングの「使った分だけ」という原則についてもっとも近い考え方です。

特にここにきて注目されている要因は2つあり、(1)クラウドプラットフォーム側がリクエスト単位に実行環境を準備できるようになった(後述:関連するパラダイムシフト)という話と、(2)ユーザーが、クラウドの特徴を活用する前提でアプリと統合されたアーキテクチャをはじめから考えるようになってきたことでServerlessifyしやすくなってきたという認識です。

martinfowlerブログ(執筆者はMike Roberts氏)に記載されているように活用形態として代表的なのが「UIドリブンアプリケーションのバックエンド」と「メッセージドリブンアプリケーション」というのが現在の共通認識ですが、今後はプラットフォーム側の提供するソリューションの拡大や、ユーザー側の使い方によってもう少し対象範囲が広くなっていくかもなと思っています。

martinfowler.com

あと、元A Cloud GuruのAntのスライドも、マネージドなSaaSからサーバーレスなサービスまで広く整理するにおいて非常に分かりやすいです。

http://www.slideshare.net/acloudguru/ant-stanley-being-serverlesswww.slideshare.net

関連するパラダイムシフト

プラットフォーム側の実装がリクエスト単位に実行環境を準備できるようになった背景として、ここ20年くらいのパラダイムシフトを挙げるとすると以下のようなものがあると思います。

  • ライセンス形態によりポータビリティの束縛があるプロプライエタリソフト→依存性を解決するパッケージシステムを通じてどこでも実行環境が構築可能なOSSの利用が増えたこと
  • Infrastructure as Codeによるアプリ/インフラともにソフトウェアのベストプラクティスを適用して管理するのが一般的になってきたこと
  • Dockerイメージなどのコンテナイメージを用いて即座に実行環境を準備可能とするリソース調達モデルの変化(※俗にまるでCGIのような実行環境の調達方法と言われる)※プラットフォーム側としてはこれが直近で非常に大きい
  • 機能ごとにマイクロサービス化するためにREST APIで機能を束ねてインタフェースを担わせるアーキテクチャの普及や期待値の高まりにより、インタフェース部分の汎用化・標準化が進んだ→インタフェースさえ変わらなければ自分の環境だろうがどこかのクラウドサービス上だろうが機能ごとにポータブルに配置可能となった ※利用者側の変化としては直近でこれが大きい
  • などなど...

これらがすべて合流した結果がFaaSやAPIを活用したサーバーレスアーキテクチャに結びついたものと個人的にとらえています。

活用シーンの例

代表的なものとして以下のような物が考えられます。自分の組織で管理するもよし、SaaSも活用するもよしです。

  • APIサービスとして単機能をAPI Gateway+Lambdaで実装する。認証/認可を行い属性やステータスを管理するDBサービスなど。
  • シングルページアプリケーションのバックエンドをAPI Gateway+Lambdaで機能実装する。あるいは静的ページであれば(HugoやStaticPress)S3に配置し必要に応じてCloudFrontやACMを設定して配信する。
  • iOSアプリやAndroidアプリのバックエンドをAPI Gateway+Lambdaで機能実装する。
  • ログが格納されたらイベントドリブンで解析して、結果をどこかに永続化して、またイベントを発火して終わる。
  • などなど...

Serverlessはベンダーロックインか?

理想から言うとむしろアプリのポータビリティが上がるので逆ですね。コードを持ち込むだけだったり(FaaS利用)、インタフェースが標準化されたり(REST APIベース)、あらゆるプラットフォームにデプロイできたりその定義を再利用できたり(フレームワーク)という方向に向かっているので、将来的な心配はしなくていいのではないかと思います。

そもそもベンダーロックインが「悪」だとされるのは「ライセンスを資産として買い切りさせられるために減価償却の5年間は乗り換えられない」「仕様がブラックボックスなのに、バグっぽい挙動を問い合わせるためには細かい情報を自分で収集して提供しないといけない(ベンダーとユーザーの情報の非対称性)」などを指して言われることが多いと思うので、ここらへんがクリアになるようにプラットフォームを選定しておけば問題ないと思います。

FaaSやAPI以外へのサーバーレスの拡大の可能性

現状のFaaSは単一コアでの一定時間/メモリ量でのコード実行に限られており、Hadoopのような並列分散処理のようなことを簡単には実現できない(S3に上げたデータをLambdaで切り分けてDynamoDBに入れてから各データを並列実行とか実装するだけでだいぶしんどいしディスクやネットワークのIOを最適化できない)です。プラットフォームの中身を気にしなくてもそういった処理が現実的な処理時間やコストで実現可能になる可能性はあると思います。

エラー処理の作りやすさや、複雑なワークフローのジョブネットを簡単に構築できたりというあたりも今後より重要視されてくるかもしれません。

運用のResponsibility、NoOps

通常Opsはカスタマーに提供するサービスレベルを設計し、十分担保できる技術を採用したりサービスを採用したりしますが、いわゆる世に出回っている便利なSaaSにはこのサービスレベル設計において必要な情報(SLA、SLO、内部仕様の公開、トラブルシュートのためのドキュメント、などなど)が足りてない傾向にあることはたしかです。お金を払ってサービスを利用しているからといってそれを用いてカスタマーに提供しているサービスの最終責任者が自分であることには変わりません。そのSaaSがSPoFにならないか、トラブった場合にどう影響範囲を切り離したり別のサービスに切り替えたり、あるいは縮退運転するか、などは自分で考える必要があります。

そういったもろもろをPodcastで語ってみました

cloudinfra.audio

ServerlessConfはどんなイベントか

ベンダーニュートラリティ

今後のサーバーレスの広がりを考えると、特定のベンダーだけが得意な分野ではなくなっていくものと推定されます。なぜなら、UIドリブンアプリケーションやイベントドリブンアプリケーションという、Webシステムの文脈だけでなく、たとえば大規模分散コンピューティング環境や、IoT、音声認識やテキスト分析、深層学習といった分野でもServerlessでアプリ利用する瞬間だけ実行環境が用意されるというモデルに近づくことが予想されているからです。

ということで、当初からそういった文脈をすべてオープンに受け入れて会話できる新しいコミュニティが必要だなと認識しており、いい機会だったので日本市場でのServerlessConfの実施のライセンスをしてもらったのが発端です。

やっていく気持ち

ということで、サーバーレスは「ユーザーがポータビリティの高いコードやインタフェース定義を作ることに専念し、自分の要件に合ったプラットフォームを選別して(あるいは適切なプラットフォームがなければそれは自分で作るかもしれないが)、その知見を共有しあいながら議論を高めていける」極めてフェアなプラットフォームの利用形態ではないかと考えています。

よってこのコミュニティに現在大事なのは、どのようにしてポータビリティの高いアプリを作り、プラットフォームやツールを選別しているかといった知見を自分自身で体験して共有するということであり、自分がその議論を先導するための「やっていく気持ち」をもって取り組むことだと思います。

スピーカーとスポンサーを募集しています

ということでServerlessConf Tokyoではスピーカーとスポンサーを募集しています。どちらもサイトから必要事項を添えてメールでご応募ください。

tokyo.serverlessconf.io

スピーカー

上記で述べたようにさまざまな文脈が入り混じって混沌としているのが現在のサーバーレスです。自分はこの分野においてサーバーレスとの関係をこう考えている、などの意見を積極的に発表していくことが、日本におけるサーバーレスの文脈の深化につながっていきます。

以下のような文脈を想定しており、すでにかなりの応募をいただいています。第1弾としては8/8(月)くらいまでには選定したいと思っています。

  • サーバーレスな環境を提供するプラットフォームの話
  • サーバーレスを便利に利用するフレームワークの話
  • サーバーレスを使った開発の話
  • サーバーレスを使ったOpsの話

スポンサー

ServerlessConfはサーバーレスの活用を推進するたくさんのエンジニアによって構成され、参加者の幅はフロントでJSをコーディングしている人からインフラを作っているエンジニアまで多岐に広がっています。このリージョナルイベントをスポンサーシップとして応援してください。また、今後Meetup系の小規模イベントを合同企画させていただくことも可能になると思います。興味があればぜひお問合せを。

先週のAWS関連ブログ〜8/3(水)-ServerlessConf Tokyo、EMRのSpark 2.0対応など

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

シン・ゴジラ見てきました。

前半の前例主義や現状維持バイアスから事態が急速に悪化していくあたりや、それでも最後まで書類仕事でゴジラに立ち向かう日本の閣僚機構がとても面白かったです。一緒に見た息子はそこらへんはいまいちパッとしなかったらしいですがゴジラの熱線の圧倒的な破壊力に大興奮はしていたみたいです。

ちなみに我が家は前半どこかのタイミングでゴジラの一蹴りで粉砕されていたような気がします。

それでは今週も行ってみましょう。

AWS公式

1. Amazon EMR 5.0 リリース

  • Spark が1系から2.0に。Hiveが1系から2.1に。TezがMapReduceにかわりHiveとPigのデフォルトエンジンになった。
  • EMRジョブの失敗をコンソールから確認(スタックトレースの一部を表示し、詳細はS3内の当該ログへのリンクを表示)できるようになった。

リンク:Amazon EMR 5.0.0 – メジャーアプリアップデート、UI改善、デバッグ改善、その他 | Amazon Web Services ブログ

2. AWS Application Discovery Service

  • Application Discovery Serviceを使うと、アプリケーションをクラウドに移行するために現環境(オンプレミスなど)のホストにエージェントをインストールして移行計画のためのパフォーマンス情報などのシステム情報を収集することができるが、エージェントを現環境にインストールしにくい場合のオプションとして、VMware vCenter 上のVMでアプリケーションが稼働している場合、vCenter側でゲストVMの情報を収集することができるオプションを用意した。
  • ただし、通常のゲストOS内にエージェントをインストールする場合と違い、ゲストOS内のインストール済みソフトウェアなどは把握できないことに注意。

リンク:AWS Application Discovery Service アップデート – VMware のエージェントレス検出 | Amazon Web Services ブログ

3. AWSの各種サービスがPCI DSS 3.2に準拠

  • 一定規模以上でクレジットカード決済を行う事業者は準拠が必要になるPCI DSS、最新セットである3.2にAWSが対応したことで、AWSを利用している決済事業者は引き続き、AWSより上の部分の準拠に対して専念すればよくなる。
  • 私が技術顧問を務めているCloud Paymentでもほぼ定常的にPCI DSSの最新セットへの対応が必須であり、AWSがこうやって早い時期に最新セットに準拠してくれて、かつ追加でWAFやConfigが準拠してくれたことは、これから3.2への対応を計画する事業者にとって計画の対象範囲や、代替コントロールなどによる手間を減らすことができて非常に評価が高いと言える。

リンク:AWSが新しいPCI DSS 3.2を採用する最初のクラウドサービスプロバイダに | Amazon Web Services ブログ

4. Cognito User Poolsが東京リージョンに来て、さらにGAに

  • モバイルアプリやウェブアプリのユーザーの情報管理や、認証機能を提供するCognito User PoolsがGAになり、同時にMFAの強制や全端末からの強制サインアウト、SES経由での送信アドレスの変更など大幅にアップデート。
  • API Gatewayとの統合機能も追加され、APIアクセスの認証プロセスにUser Poolsを利用可能になった。
  • (蛇足)GAは一般利用可能になったという意味であり、SLAが設定されたわけではない。

リンク:Amazon Cognito Your User Pools - 一般提供を開始 | Amazon Web Services ブログ

5. RDS for SQL ServerがAmazon S3を使ったネイティブバックアップと復元をサポート

  • 今までオンプレ→AWS移行時にはバックアップファイルのブロックストレージへの持ち込みが必要だった(リストアの読み出しのため)ため、移行用のEC2などのサーバーが必要だったが、これを用いることでオンプレミス側から直接S3にアップロードしてそれを読みだすリストアが可能になった。
  • また、RDSのバックアップはポータビリティが低いが、ネイティブバックアップをS3に置いておけば、開発環境としての手元やオンプレミスや他社クラウド環境へのリストアも可能になる。

リンク:Amazon RDS for SQL Server – Amazon S3 でネイティブバックアップと復元をサポート | Amazon Web Services ブログ

6. 【イベント開催】Thanks for coming AWS GAMEDAY JAPAN!!!

  • 昨年のGAMEDAYが翻訳されて日本でも開催。
  • 非常に実践的な問題で面白かったです。
  • 初老丸の影に隠れてますが僕ら当日ボッチを集めて結成した「Section-3」も3位だったんですけどね。全然目立たないけど。

リンク:【イベント開催】Thanks for coming AWS GAMEDAY JAPAN!!! | Amazon Web Services ブログ

7. Amazon Prime Day

  • AWSのビッグカスタマーであるAmazonが先日実施したPrime Dayにおいて1日における売上が過去をはるかに上回る最大の売上となった模様。
  • 全世界でのこの1日イベント(といっても日本を含む極東から開始するので合計40時間)でクリックストリームは850 億件、DynamoDBへのリクエスト数は560億件以上。CloudWatchメトリクスが通常の曜日の4倍以上ということで、売上も普段に比べて4倍以上ということだろう。
  • Amazon 全体でAWSのサービスを38種類使っていたらしい。

リンク:AWS が Amazon の記録更新に貢献 | Amazon Web Services ブログ

8. Amazon AuroraでMySQLバックアップからクラスタを作成可能に

  • Percona Xtrabackupを用いてmysqldumpの20倍高速に移行可能になった。

リンク:Amazon AuroraでMySQLバックアップからクラスタを作成可能になりました | Amazon Web Services ブログ

9. その他

AWSサポートの「開発者」プランのスタート料金が値下げに。

ただし上限が利用料に連動するように変わっているのでそれなりの料金を「開発者」で利用している場合には値上げとなる場合もあることに注意。(つまりAWS的には、かなり利用している=ビジネス利用だろうからそこは定額の開発者プランだと合理的でないという判断だろう)

AWS CodeCommit がコミット履歴表示を追加

CodeCommitのWebコンソールは基本的にリポジトリ作成時以外に見ない人が多いと思うが、この画面にコミット履歴が表示されることで、ちょっとした確認がしやすくなっている。

AWS関連

10. ServerlessConf Tokyo開催(ロンドンも開催決定)

  • ティザーサイトが公開された。
  • CFPとスポンサーを募集中。

tokyo.serverlessconf.io

11. 実践SERVERLESS

  • 「サーバーレスコンピューティングの紹介」「LambdaとAPI Gatewayを管理するフレームワークツールの比較」「Cognito User Poolsの話」
  • 個人的に面白かったのはフレームワークツールの比較、なんだかんだ全ては試せてないので。

dev.classmethod.jp speakerdeck.com speakerdeck.com

12. StaticPress Proをベータリリース

  • WordPressのプラグインとして有名なStaticPressをサービスとして利用可能なStaticPress Proがベータでリリースされ、クローズドβ登録が開始した。
  • StaticPressはWordPressのサイト全体を静的サイトに吐き出すことで、S3や軽快なWebサーバーからの発信ができるようになるサーバーレスな解決方法の一つである。

labs.digitalcube.jp

その他

13. AWSが好調

  • 最近ほぼ値下げをしなくなったAWS、キャッシュフローはいいから、今後大型の投資などにお金を使っていくのかもしれません。

note.mu

先週のAWS関連ブログ〜7/17(日)-AmazonにおけるCPUとGPUのハイブリッドクラスタ管理、Lambdaを使ったさまざまなサーバーレスなサンプル実装例など

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

AWSの各種公式ブログで紹介される効果的なアーキテクチャにおいて、LambdaやAPI Gatewayを利用したサーバーレス構成が非常に多くなってきた印象です。はじめはとっつきにくいのが正直なところかと思いますが、スケーラビリティの管理やホストのメンテナンスなどから解放される効果は絶大です。少しずつ触ってみましょう。

AWS公式

1. ECSタスクのためのIAMロールによってコンテナ利用アプリケーションをより安全にする

  • ECSではコンテナからIAMロールの権限でAWSリソースへのリクエストができるので、環境変数にクレデンシャルを設定する必要がない。
  • 新機能は、ECSタスク単位にIAMロールを指定できるので、ホストのロケーションに関係なく、また1つのクラスタ内に複数のECSタスクを実行し、それぞれが別のリソースへのアクセス権限が必要な場合もホストに依存しないタスク単位のIAMロールの指定が可能になった。その際、クラスタ内のホストにはAmazonEC2ContainerServiceforEC2RoleポリシーがあたったIAMロールがあたっている必要がある。
  • 注意点としては、同一クラスタ内に複数のECSタスクを別IAMロールで同居は可能になったが、セキュリティグループは依然ホスト単位にかけるものなので、どのECSタスクが載っているかによって変更ができない点。

ECSタスクのためのIAMロールによってコンテナ利用アプリケーションをより安全にする | Amazon Web Services ブログ

2. Amazon Inspector でセキュリティ脆弱性テストを拡大

  • Amazon Inspectorでチェックしたセキュリティ脆弱性の診断終了の通知をSNSトピックに発行し、それをトリガにAWS Lambdaを使って「OKじゃなかった場合だけEメールに通知する」サンプル。
  • 簡単な実装だけどエラーハンドリングもそこそこ入ってるのでこのまま使えそうな内容。

Amazon Inspector でセキュリティ脆弱性テストを拡大 | Amazon Web Services ブログ

3. Apache SparkとAmazon DSSTNEを使った、Amazon規模のレコメンデーション生成

  • AmazonがOSSで公開しているGPU上で動作するディープラーニング用エンジンDSSTNE(the Deep Scalable Sparse Tensor Neural Engine)は、実際にAmazonのECサイトやデバイスにおけるパーソナライズに活用されている
  • 学習や予測データの作成に使うSparkはCPUで稼働し、ディープラーニングするDSSTNEはGPU上で稼働するため、CPU用インスタンスとGPU用インスタンスをハイブリッドでクラスタ管理するのは非常に難しい。
  • Spark (CPU)のクラスタはAmazon EMR上で実行し、GPUのインスタンスはAmazon ECSで管理することにし、ECSへのタスクのトリガなどはEMR側で管理することで統合されたクラスタ管理ができるようになった。

aws.typepad.com

4. AWS Marketplace が EU の独立系ソフトウェアベンダー (ISV) のサポートを開始

  • 今までUS国内に住所と銀行口座があるパートナーに限られていたMarketplaceへの出品がEUにも拡大。
  • 営業/回収の手間が不要なソフトウェア販売のプラットフォームとして、すでに日本から世界に(アメリカに会社を設立し)AMIMOTO AMIを販売して急伸しているDigitalCubeのような例もあるので、今後日本にも拡大するようであれば大歓迎したい。

AWS Marketplace が EU の独立系ソフトウェアベンダー (ISV) のサポートを開始 AWS Marketplace Update – Support for ISVs Based in the EU | AWS News Blog

5. AWS CodePipeline に手動承認機能を追加

  • AWS CodePipelineの各ステージに手動承認が設定可能になり、レビュー&承認、リリース承認などができるようになった。
  • 多くのAWS上のワークフローが「作業者の権限において実施するのみ」であるのに対し、この機能で「(事後承認ではない)統制管理が可能」になったことは非常に意義深いと感じる。特に統制といったあたりを気にする必要がある組織にとっては。

AWS CodePipeline に手動承認機能を追加

6. CloudiaJSを使いAWS LambdaとAPI Gatewayで5分でFacebook MessengerのチャットBotを作る

  • ホントに簡単にデプロイまでできる

Create and Deploy a Chat Bot to AWS Lambda in Five Minutes | AWS Compute Blog

7. サーバーレスでプライベート用短縮URLサービスをつくる

  • サービスのシングルページをS3(CloudFront)から配信し、S3にホストしたファイルのURLを短縮する時に、API Gateway経由でLambdaファンクションをコールし、HTTPリダイレクトのための短縮文字を生成し、S3のメタデータに設定する。
  • CORS設定を避けるためにすべてのリクエストはCloudFrontで受けて配信するように設定する。
  • 上記の設定ができるCloudFormationテンプレートが公開されている。
  • 1月に1000件短縮して1000ユーザーから利用されても12セント(約12円)

Build a Serverless, Private URL Shortener | AWS Compute Blog

8. RとLambda、API Gatewayを利用したゲノム解析

  • Station XではAmazon LinuxにR環境をセットアップしライブラリなどを整えてLambda用のパッケージを生成しデプロイし、同期リクエスト用にAPI Gatewayをセットアップし、遺伝の影響によるがん患者の生存率の計算に利用している。

Analyzing Genomics Data at Scale using R, AWS Lambda, and Amazon API Gateway | AWS Compute Blog

9. 特定のIAMロールからS3バケットへのアクセスを制限する方法

  • (IAMロールとIAMユーザーにS3フルアクセスのポリシーがアタッチされている状況で)一方のS3バケットポリシーにIAMロールのみアクセス可能と記載すれば、一方のバケットのみIAMユーザーからのみアクセスが遮断できる。
  • スイッチロールでクロスアカウントアクセスするロールユーザーとアカウントのIAMユーザーは混在している場合、バケットポリシーでユーザーIDを指定して拒否するのと同時に他のアカウントからアクセスすることになるロール名を許可指定する必要がある。
  • ここらへん、実際に必要になる場面が結構多いですが大抵の人はハマるとこですので、原理は押さえておきましょう。

http://blogs.aws.amazon.com/security/post/TxK5WUJK3DG9G8/How-to-Restrict-Amazon-S3-Bucket-Access-to-a-Specific-IAM-Role

10. 地球観測衛星のビッグデータを一般利用(有料)できるSentinel Hub

  • 地球観測衛星Sentinel-2は6ヶ月の試運転期間に200TBものデータ(250兆ピクセル)を生成したが、90%以上のデータが再利用されずにいる。
  • このパブリックデータ・セットはS3上で公開されているが、効果的にアクセスするためにSentinel Hubというサービスを作り、必要な範囲で必要なデータのみをクエリに応じて描画できるようにした。
  • これにより、たとえば特定範囲の最新の航空写真を「雲を取り除く画像処理をLambdaを使って実行して」、閲覧するということが可能

A Minimalistic Way to Tackle Big Data Produced by Earth Observation Satellites | AWS Public Sector Blog www.sentinel-hub.com

11. 【開催報告】アドテクノロジー業界セミナー #AWSAdTechJP

  • アドテクは日々進化している。
  • Amazonのミッションは「undifferentiated heavy lifting (差別化につながらない重労働)」の排除
  • デファクトになりつつあるSparkと、Sparkで処理したデータをためてOLTP処理に利用したりできるDruidの紹介
  • その他各社発表があって盛り上がった模様

aws.typepad.com

undifferentiated heavy liftingの排除についてはこちらの記事も参考に

http://archive.oreilly.com/network/2006/12/20/web-20-bezos.html

http://www.cio.co.nz/article/466635/amazon_cto_stop_spending_money_undifferentiated_heavy_lifting_/www.cio.co.nz

www.slideshare.net

AWS関連

12. AmazonがCloud9を買収

  • おそらくこれはサービスに統合してコードを書いたらすぐにデプロイできるようにするでしょうし、re:Inventあたりが楽しみですね。

www.publickey1.jp

13. チームによる継続運用を意識したAWS環境におけるTerraformの活用

  • うちでも同等のTFによるチーム開発実践してたので分かりますがベストプラクティスに近いと思いますね。
  • 書いていないところで言うとplanはうまくいってもapplyで失敗するときにどうするかとか、RDSのプロビジョニング時間の長さでTFがタイムアウトするのどうするとか、実態とtfstateがズレた場合に手書きで直すかどうするか、などでしょうか。

made.livesense.co.jp