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

AWS - アップデートまとめ

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

だいぶ間が開いてしまい恐縮ですが、5/12(木)から6/1(水)まで3週間分のアップデートをふりかえってみましょう。

AWS公式

1. EC2 Run Commandアップデート – コマンドの管理と共有など

  • WindowsおよびLinuxのインスタンスに外部からコマンド実行を指示できるEC2 Run Commandがアップデートされた
    • Windows用の事前定義コマンド（インベントリ情報収集、未適用のWindows Updateのリスト化、KB単位でインストール実行）が追加され、メインテナンスを支援してくれる
    • 共有されているドキュメントや実行可能なパラメータを選択して自分用のカスタムコマンドが作成可能になった。これはPublicに公開することも、特定のアカウント間でのみ共有することも可能
    • インスタンス用Simple Systems Manager (SSM)エージェントのLinux版がGitHubで公開された

リンク：EC2 Run Commandアップデート – コマンドの管理と共有など | Amazon Web Services ブログ

github.com

2. [新サービス]AWS Application Discovery Service – クラウド移行計画

  • クラウド移行計画(現在のIT資産を評価→調査と計画策定→構築→稼働)を推進するための新しいサービスを発表した
  • 「The Discovery Agent」と呼ばれるエージェントをオンプレのサーバーに入れてシステム情報を収集する仕組み
    • エージェントは収集した情報をオンラインであればポート443でやりとり、オフラインであればローカルに保存される
    • エージェントが対応してるOSはUbuntu 14、Red Hat 6-7、CentOS 6-7、そしてWindows (Server 2008 R2、Server 2012、Server 2012 R2)
  • Application Discovery ServiceのCLIやSDKからも操作が可能

リンク：New – AWS Application Discovery Service – クラウド移行計画 | Amazon Web Services ブログ

3. AWS Config – タグの変更検知の高速化、新しいマネージド ルール追加、およびユーザビリティの向上

  • AWS Config Rulesが改良され、タグの変更後、数分以内にタグ変更の通知を受け取りrequired-tagsが素早くチェックされるように
  • マネージドルール(AWSが提供するルール、他に自分でカスタムして作成も可能)にIAMユーザにMFAが有効になってるかチェックも追加された → https://github.com/awslabs/aws-config-rules
  • その他：
    • Config Rulesコンソールから準拠/非準拠の注釈を確認することができるようになった(UIの改善)
    • Config Rulesの詳細ページからルールの呼び出しができるようになった(機能追加)
    • 評価の際のタイムスタンプ等、より細かい粒度のステータスを受け取ることができるようになった(機能追加)

リンク：AWS Config – タグの変更検知の高速化、新しいマネージド ルール追加、およびユーザビリティの向上 | Amazon Web Services ブログ

4. EC2のX1インスタンス – メモリー重視のワークロードに対応可能

  • 昨年秋、AWS re:Inventで発表されていたX1インスタンス( x1.32xlarge )がローンチされた
  • スペック
    • 2.3GHzの4 x Intel™ Xeon E7 8880 v3 (Haswell) – 64コア / 128 vCPUs → ターボブースト2.0で最大3.1GHzまでクロックアップ
    • メモリー： Single Device Data Correction (SDDC+1)を実現した1,952 GiB → ほぼ2TB！
    • インスタンスストレージ： 2 x 1,920 GB SSD → 揮発性のストレージなのでスワップや一時領域に使う想定
    • ネットワーク帯域幅： 10 Gbps
    • 専用のEBS帯域幅： 10 Gbps (デフォルトでEBS最適化、追加料金不要)
  • 現状では利用申請が必要
  • SAPなどに利用する想定
  • 料金：東京リージョンにおいて、オンデマンドで1時間あたり $19.341、1年すべて前払い($97438：約1000万)で$11.123、3年すべて前払い($142204：約1500万)で$5.411

リンク：EC2のX1インスタンス – メモリー重視のワークロードに対応可能 | Amazon Web Services ブログ

5. I Love My Amazon WorkSpaces!

  • WorkSpaces、クライアント・アプリケーションから使うのもいいが、最も体験が良いのは「Zero Client」
  • ラップトップが死んでも大丈夫

リンク：I Love My Amazon WorkSpaces! | Amazon Web Services ブログ

6. Amazon Auroraでアカウント間でスナップショットを共有できるようになった

  • スナップショットをアカウント間で共有可能になった

リンク：Amazon Auroraでアカウント間でスナップショットを共有頂けるようになりました | Amazon Web Services ブログ

7. Amazon ECSでAuto Scaling

  • これまでECSでAuto Scalingするためには、Auto Scalingと、増加したインスタンスでCloud Initの実行を行うという方法が提案されていたが、今回はCloudWatchのアラームがECSサービスに対応したのでこれを用いて「ECSクラスタのスケールイン/アウト」と「ECSサービスのスケールイン/アウト」を組み合わせてAuto Scalingできるようになったので、その構成方法を紹介している
  • 構成上、ECSクラスタの増減のほうが時間がかかり（EC2をプロビジョニングするため）、ECSサービスの増減と実際の運用ではうまくバランスを調整する必要がある
  • 特にAuto ScalingでSpot fleetなどさらに組合せを考慮するとクラスタとサービスのリードタイムの乖離が大きくなりがちだと想定されるので、つねにクラスタ>サービスとなるような構成とすることと、スケールのスピードをバランスする設定での運用が必要になると思われる
  • 現在はまだバージニア/オレゴン/アイルランドのみ

リンク：Amazon ECSでAuto Scaling | Amazon Web Services ブログ

8. Amazon Elastic TranscoderでMPEG-DASHをサポートしました

  • 通常、アダプティブストリーミング（ネットワークの状況に応じて、高ビットレートの映像の映像片を返すか低ビットレートにするか調整してストリーミングをスムーズにする）のためには、高ビットレート〜低ビットレートまで何種類かの映像片に変換して準備しておく必要があった。これをMPEG-DASHではコンテンツの変換時にさまざまなビットレートのセグメントを用意する規格なため、これに対応したTranscoderを利用すれば、ユーザー側で複数のビットレートのファイルに変換をかける必要がなく、1プロセスでコンテンツの準備ができるというもの。
  • また、セグメントの秒数が指定できるので、細かくすればするほど回線状況の変化にすばやくセグメント変更が対応できるようになる

リンク：Amazon Elastic TranscoderでMPEG-DASHをサポートしました | Amazon Web Services ブログ

9. EC2インスタンスのコンソールスクリーンショット

  • インスタンスの標準出力の状況をSSHやRDPでつないで確認する手間を省けるように、マネジメントコンソールから画面スナップショットを取得して表示することができるようになった
  • ちょっとした確認がすばやくできて便利

リンク：EC2インスタンスのコンソールスクリーンショット | Amazon Web Services ブログ

10. Amazon RDS for Oracleで拡張モニタリングが利用できるようになった

  • 唯一対応していなかったOracleでも拡張モニタリングが可能になった
  • 56種類のメトリクスを1秒単位で取得可能【PGA/SGAなどの値とメモリのメトリクスの対応関係は別途まとめるつもり】

リンク：Amazon RDS for Oracleで拡張モニタリングがご利用頂けるようになりました | Amazon Web Services ブログ

11. Amazon ElastiCache アップデート – RedisのSnapshotをAmazon S3へエクスポートする事が可能になりました

  • ElastiCache for Redis、今までS3からRDBファイルをインポートすることはできたが、エクスポートはできなかった。今回はエクスポートに対応。しかもRDBファイルなのでクラスタ再構築（スケール変更のためなど）や共有に使うことができる
  • バックアップはスナップショットで定期的にやっておいて、移行や共有はRDBファイルで行うという使い分けができそう

リンク：Amazon ElastiCache アップデート – RedisのSnapshotをAmazon S3へエクスポートする事が可能になりました | Amazon Web Services ブログ

12. Amazon AuroraでCross-Region Read Replicaが利用できるようになった

  • Auroraのリードレプリカを他のリージョンに作成することが可能になった
  • このレプリカをマスターに昇格できるのは暗号化されていない場合のみ
  • binlogも有効にしておくこと（binlog_format=MIXED）

リンク：Amazon AuroraでCross-Region Read Replicaがご利用頂けるようになりました | Amazon Web Services ブログ

13. Amazon RDSがMariaDB 10.1をサポートした

  • MariaDB 10.1をサポートしたことで、以下のような機能が利用できるようになった
    • XtraDB/InnoDB page compression
    • XtraDB/InnoDB data scrubbing
    • XtraDB/InnoDB defragmentation
    • Optimistic in-order parallel replication
    • ORDER BY optimization
    • WebScale SQL patches

リンク：Amazon RDSでMariaDB 10.1をサポートしました | Amazon Web Services ブログ

14. AWS KMSを使ってS3のオブジェクトを暗号化するためのREST APIの使用法

  • AWS Key Management Service(AWS KMS)を使ってS3のサーバーサイド暗号化とクライアントサイド暗号化を行う際のREST APIの利用方法
  • 通常、SDKで暗号化することが多いが、クロスプラットフォームで利用できる（言語のロックインに悩まなくていい）のがメリット

aws.typepad.com

15. Amazon Route 53で登録可能なドメインが増えた

  • .name, .online, .uk, .org など300以上のTLDが追加された
  • ドメインについての詳細な操作履歴が取得可能になった

リンク：Amazon Route 53 Announces Domain Name Registration Enhancements: Expanded TLD Catalog, Detailed Billing History, and Amazon Registrar support for .ORG

16. ECSがDocker 1.11をサポート

  • ECS利用時にホストに指定する最新のAmazon ECS-optimized AMIでDocker 1.11をサポート
  • 従来のホストであれば単純にアップグレードすれば同様に1.11を利用可能

リンク：Amazon EC2 Container Service Supports Docker 1.11

17. Amazon Redshiftの改良

  • バージョン1.0.1012以上で、SELECT INTO TEMP TABLEで一時テーブルを作成するスピードが2倍になった
  • バージョン1.0.1056以上で、クエリのスループット（一度に処理可能なワークロード）が2倍になった
  • バージョン1.0.1056以上で、VACUUMのパフォーマンスが10倍以上になった
  • バージョン1.0.1057以上で、UNION ALLのクエリの処理速度が10倍以上になった

リンク：Amazon Redshift improves throughput performance up to 2X リンク：Amazon Redshift UNION ALL queries and VACUUM commands now run up to 10x faster

18. AWS Certificate Managerが東京リージョンにも来て(ELBで利用可能に ※CFはすでにサポート済み)、Beanstalkでもサポートされた

  • AWS Certificate Managerが東京リージョンを含む多数のリージョン（ノーカル/オレゴン/アイルランド/フランクフルト/ソウル/シンガポール/シドニー/サンパウロ）に対応した
  • Elastic BeanstalkからACMの設定が可能になった

リンク：AWS Certificate Manager now available in more regions リンク：AWS Elastic Beanstalk Supports AWS Certificate Manager

19. Amazon Elasticsearch Serviceの制限が緩和された

  • データノード10台/マスターノード1台 → データノード20台/マスターノード5台
  • これによりi2.2xlの場合、今まで4TB〜8TBだった最大データ量を12TB〜24TBに拡張可能になった

リンク：Amazon Elasticsearch Service Increases Domain Limits

20. Amazon Kinesis FirehoseでRedshiftへのデータロードにリトライウィンドウを設定可能になった

  • RedshiftへのCOPYコマンドの実行が失敗しても7200秒以内の間隔を指定して再実行するように設定が可能になった
  • Kinesis Firehoseのスケーラビリティ(1000リクエスト/1シャード単位にスケール可能)に比べて容易にスケールしにくいRedshiftにおいて、再実行で同期処理の制約から解放されるため、より安心して使えるようになりそう

リンク：Amazon Kinesis Firehose Supports Configurable Retry Window for Loading Data into Amazon Redshift

21. Amazon WorkSpacesがタグをサポート

リソース：Amazon WorkSpaces now supports tagging

22. NIST 800-53クイックスタートガイドをアップデート

  • NIST 800-53をリビジョン4に
  • NIST SP 800-171をスコープに追加
  • The OMB Trusted Internet Connection (TIC) Initiativeをスコープに追加
  • The DoD Cloud Computing Security Requirements Guideをスコープに追加

リンク：Standardized Architecture for NIST-based Assurance Frameworks on the AWS Cloud: Quick Start Reference Deployment

23. API GatewayとVPC endpointsをAWS Lambdaでつないでインターネット接続のないVPC内のリソースにHTTPでリクエスト/レスポンスする

  • Lambdaを使ってプライベートサブネット内のリソースにREST APIアクセスをする方法

リンク：Using API Gateway with VPC endpoints via AWS Lambda | AWS Compute Blog

S3とDockerを使ってECSアプリケーション(WordPress)のシークレットを管理する方法

  • DockerベースのWordPressをECSに載せて、クレデンシャルをS3に配置し、VPC Endpoint for S3経由でEC2のRolleを用いて安全にアクセスする方法

リンク：https://blogs.aws.amazon.com/security/post/Tx2B3QUWAA7KOU/How-to-Manage-Secrets-for-Amazon-EC2-Container-Service-Based-Applications-by-Usi

ということで3週間で結構なアップデートがたまってましたが、振り返ってみると引き続き機能追加など改良のスピードが早いことを実感させられました。

今日から始まっている AWS Summit Tokyo においてはさらに、

東京リージョンでRDS SQL ServerのMulti-AZ化が間近

東京リージョンでも近いうちにAWS Import/Export Snowballが利用可能に

といった話が聞こえてきてます。楽しみですね。

ServerlessConf Day2

AWS Serverless

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

ロウアーマンハッタンのあたりを走ってみました。たくさんのランナーがいて、ニューヨーカーはホントに健康意識が高いんだなと感じました。ブロックごとにジムもあり、体型を気にしている人も多いんですね。西海岸に比べてスタイルのいい人が多かった印象でした。

今回、宿はAirbnbを使ってホストさんの家の一部屋を借りたのですが、ランニングのおすすめルートを話したり、飼っている犬と遊んだら3日間ずっとなつかれたりと、ホテルで一人で泊まるよりも居心地が良かったです。移動の足もすべて恒例のUberでしたし、こちらのユニコーンは本当に使われている（使わない場合に比べて明らかに良い体験ができる）んだなと感じました。

では2日目のレポートです。

ServerlessConf Day2 report

Old Programmers Can Learn New Tricks

  • Dr. Donald Ferguson - SparqTV

  • API GatewayとLambdaを用いたAPIにおけるバージョン管理の話や、ハイレベルなアプリケーション・アーキテクチャの話
  • AngularJSなどで構築するフロントから、Integration Composition Servicesというリクエスト/レスポンスを統合管理する層を通じて、ユーザー情報（認証/認可/ユーザーマスター）やコンテンツマネジメント、ソーシャルメディアなどそれぞれ独立したマイクロサービスに対してAPIアクセスを行うアーキテクチャを説明
  • インタフェースや実装のモデルについて
    • インタフェースはREST、リクエスト/レスポンスはJSONで
    • Lambda Functionに引数を渡すことで複数の処理にディスパッチする層がある
    • Eclipse SDKやLambdaテストUIを用いてゲートウェイなどを介さずに直接テスト実行できるようにするためにこうした
    • このモデルであればSQSやXMPPといったバインディングにも対応できるし、1つのゲートウェイで複数のリソースやHTTPメソッドに対応することができる
  • その他
    • ウェブアプリケーションの設計方法には「データモデル→コード→API化」「API設計→コード→データモデル」の2種類あるが、われわれはデータモデルからはじめた。結果的には最後までこれで泣かされた。すべてのステージでタイプスペースとフォーマットのマッピングを行ったり、エラーが発生したりする状況だった。
    • いくつかの理由でJavaを選んだ
      • COBOLがサポートされていない
      • いくつかの再利用できるコードがあった
      • 年寄りなのでサーバーサイドのJavaScriptが怖すぎた
    • 設定やプロパティ管理は難しい
      • どこにどう格納して扱うようにするか、むしろみんなに聞きたい
      • 自分たちはさまざまな理由でいくつか別々の方法で管理している
    • ソフトウェア設定管理
      • すべて一つの方法で管理することができない
      • S3に格納してるものや、Lambda FunctionだったりSQLスクリプト、アプリを統合するマッピング定義とか
  • 要望
    • サンプルやパターンが少ないのでありとあらゆるミスをしてしまった
    • グラフデータベース
    • チャットでメッセージをコントロールに使える「サービス」
    • Functionを生成するうえでの抽象化された状態で使えるDSL

www.slideshare.net

How Firebase helps developers create extraordinary experiences

  • Mike MacDonald - Firebase / Google & Frank van Puffelen - Firebase / Google

  • Firebaseはシンプルなアイデアからうまれた
  • Firebaseはプラットフォームとして成長してきた
    • リアルタイムデータベース
    • 認証
    • ホスティング
  • Googleのサービスにおける *aaS
    • Software as a Service: Apps
    • Backend as a Service: Firebase
    • Platform as a Service: App Engine
    • Infrastracture as a Service: Compute Engine
  • 画像をアップロードしてそれをGCVで解析するデモが行われた

www.slideshare.net

Event-driven and Serverless Programming with OpenWhisk

  • Michael Behrendt - IBM & Dr. Andreas Nauerz - IBM

  • 動機とゴールへのアプローチ方法
    • 初期のサーバーレスやイベントドリブンに関する研究
    • ビジネスユーザーと開発者、両方に嬉しいことができそう
    • IBM Research(プログラミングモデルグループ)と製品開発部隊で一緒に開発を始めた
  • OpenWhiskとはなにか
    • オープンソースとして、あるいはIBM BlueMix上に展開した状態で提供される
    • 設計上の原則
      • イベント発生元に対して開放されたインタフェース
      • 多言語(Polyglot)のサポート
      • 高級プログラミング構造のサポート（たとえばシーケンス制御）
      • リクエスト単位にスケールすること
      • アクションとイベントプロバイダーを共有できるようにする
    • 環境構築について
      • NodeからはじまりScalaにスイッチした
      • DockerやKafka,consul,Akkaなどに対応していった
  • OpenWhiskはBlueMix上のコンピュートモデルの一つの選択肢
    • VM(OpenStack)やIBM Containers(Docker)やInstant Runtimes(CloudFoundry)と使い分けることができる
  • OpenWhiskのプログラムモデル
    • 「トリガ」を受けたら「ルール」にもとづき「アクション」を実行する
    • アクションはチェイン(これをやったらこれをやって、と順番に実行)することができる
    • フィードからトリガーが上がったり、REST APIでアクションを呼び出すことができる
    • 実行環境はDockerベース
  • デモを披露

www.slideshare.net

Alexa-Enabled Apps- Building Voice Experiences for Your Applications

  • Noelle LaCharite - Amazon Alexa

  • Amazon Echoはすでにもっともよく知られたAlexaエコシステムのエンドポイント、これに最近「Fire TV」もくわわった
  • 日々のアクションを声を使って簡単に実現できるようになる
  • サービス構成
    • Amazon alexa (クラウド上で提供されるサービス)
      • Automated Speech Recognition (ASR)
        • 自動会話識別
      • Natural Language Understanding (NLU)
        • 自然言語理解
      • そしてつねにこれらは学習を繰り返している
    • Alexa Skills Kit (ASK)
      • ユーザーはここでグレートなコンテンツを作ることができる
    • Alexa Voice Service (AVS)
      • AVSに対応しているechoやFireTVがあればコンテンツをどこにでも届けることが可能
  • alexaのプラットフォームはすべてAWSに載っている
    • AVSとのインタフェースのエンドポイント、ASR、NLU、TTS(Text-To-Speach)、自己学習
    • ユーザーのAlexa Skills
  • 参考資料
    • Building a How-to Skill: bit.ly/howtoskill
    • How to Build a Fact Skill: bit.ly/factskill
    • How to Build a Trivia Skill: bit.ly/alexatrivia

www.slideshare.net

Serverless Patterns with Azure Functions

  • Chris Anderson - Microsoft & Yochay Kiriaty - Microsoft

  • Serverlessは現在、PaaSの頂点である
  • Function実行フレームワークはserverlessではない
  • Azure Functionsの紹介
    • クラウドアプリが簡単につくれる
    • C#, Node.js, Python, PHP, Batchなどなどのファンクションが開発可能
    • サービス間をイベントドリブンにつなぐことができる
    • ファンクションはHTTP APIとしてたたけるエンドポイントを持つ
    • Logic Apps と簡単に統合できる

f:id:yoshidashingo:20160529204811p:plain

  • デモ
    • アップロードした画像のサムネイル生成

www.slideshare.net

Open Community; Building Welcoming Projects

  • Ryan Brown - Ansible/Serverless Code

  • ここから以降の時間は、いろんなツールの作者が話すセッションを集めた
  • まず、ツールの作者はこういうのをあらかじめ用意しておくといいよ
    • Issueを挙げるときのテンプレート
    • README.md
    • COMTRIBUTING.md
  • コミュニティとして活動したり互いに貢献しよう
    • 単純に使ってフィードバックするというのでも貢献はできる
  • ダイバーシティが大事

www.slideshare.net

The Lifecycle of Composable Serverless Apps

  • Eric Windisch - IOPipe

  • Apacheライセンス2.0で提供してるOSSのツール
  • ファンクションをチェーン実行できる
  • AWS以外でも実行できる
  • NodeJSモジュールとして提供 (その他Goライブラリをエクスペリメンタルで提供してる)
  • CLIツールもある
  • Lambdaと互換性がある

www.slideshare.net

A Toolbuilders View of Serverless

  • Mitch Garnaat - Amazon Web Services

  • われわれはツールが好きで、不満があるとインテリジェンスを発揮してツールを作ることになる
  • たとえばYeobot
    • Slackのbot
    • すべてのAWSのリソースを把握している（複数アカウントとか、リソースの依存性の状況なども）
    • ためしにリソースについて尋ねるといい。答えてくれるはずだ
  • Yeobotのインデクシングがどうおこなわれるか
    • 指定のリージョンやアカウントのリソースの情報がKinesisストリームに格納される
    • KinesisストリームがLambdaファンクションを呼び出し、結果をDynamoDBに書き込む
    • DynamoDBテーブルトリガを使ってElasticsearchにインデクシングしたり、別のDynamoDBに格納する
  • Yeobotのクエリ方法
    • コンテナ化されたインスタンスがSlackからSNSに飛んでくるイベントをwebsocketで監視
    • Lambdaファンクションがこれは動作すべき関連性があるか判断し、関係があれば別のLambdaファンクションへ処理をディスパッチする
    • 呼ばれたLambdaファンクションは処理を行ったら結果をSNSトピックに書き込む
    • SNSイベントトリガで呼ばれるLambdaファンクションがSlackにレスポンスを投げる
  • kappa
    • kappaはpython製のMVT機能を提供するツール
    • YAMLファイルにすべての情報を書いておく
    • CLIツールが基本的なCRUD操作を提供している
    • 変更部分だけアップデートされる（冪等）
  • Yeobotの論理構成
    • インデクシングするパイプライン部分
      • 5つのLambdaファンクション
      • 3つのDynamoDBテーブル
      • 1つのKinesisストリーム
    • Slackbot部分
      • コンテナ化されたインスタンス
      • 20以上のLambdaファンクション
      • 5つのDynamoDBテーブル
      • 2つのSNSトピック
  • ハイレベルな抽象化が必要なわけ
    • IAMポリシー
      • 難しい
      • 依存性などを深く理解して使わないとうまく使えない
    • DynamoDBテーブル
      • 難解なDDL
      • スキーマの定義とスループットのような設定値がDDLの中にごちゃ混ぜ
    • Cruddy
      • DynamoDBに対する単純なCRUDラッパー
      • Lambdaからも使えるし、Lambdaじゃなくても使える
      • ユーザーは"prototype"オブジェクトを保存すればよい
  • テスト
    • ユニットテスト
      • AWSのAPIコールに対するモック応答
        • レコード/プレイバック方式のplacebo ※他にもあるけど
      • Syntheticなレスポンス
        • 難しそうだけど頑張ればできそう
    • 結合テスト
      • ローカルではなくクラウドで
  • その他
    • リソースのアイソレーション
      • 複数のアカウントを使い分けているか？
      • ステージ分割やエイリアスなどを使って環境を扱っているか
    • イベントソース
      • イベントベースのプログラミングなわけで、イベントのオブジェクトが最も大事と位置づけなければいけない
    • ロギング/モニタリング
      • アプリケーションレベルでやらないといけない

Cloud Custodian - Resource Management Rules Engine

  • Kapil Thangavelu - Capital One

  • Capital OneがリリースしたOSSツール
  • インフラ管理のルールエンジン
  • YAMLでDSLを記述する
  • Lambdaやその他のイベントソースを統合して利用する
  • ロードマップ
    • Elasticsearch
    • Flourish ?? ※まだわからないけど
    • 複数言語をたまがるサポート

www.slideshare.net

The Next Serverless Framework

  • Austen Collins - Serverless, Inc.

  • スタートアップやリーンエンタープライズの世界ではあっという間にマーケットが変わっていく
  • Lambdaはコンピュートサービスの夜明け
  • 全部lambdaで作ろうぜー
  • Serverless Frameworkについて
    • 2015年7月〜 JAWSという名前ではじまった
    • 口コミで一気に広がった
    • ファンドからお金もらった
    • 2015年10〜11月 Serverless Frameworkって名前に変えた
    • Fortune 500 のエンタープライズでも使われている
    • 6人チーム
    • 0.5だけどそろそろ1.0にしようかと思う
  • チャレンジ
    • LambdaというかFaaSはマイクロサービス型のプラットフォームなので、従来のマイクロサービスが持つ課題はここでも課題になってくる
    • 複雑性
      • トラディショナルなマイクロサービスよりも多くのサービス数による構成
      • たくさんのファンクション、リソース、ステージ、リージョン、成長するチーム、プロジェクト
      • たくさんの設定やスキャフォールドや依存性
    • ベストプラクティス
      • コードをコンテナ化する
    • コラボレーション
      • サービスチーム間の自律的なコラボレーション
    • DRY
      • ジョブに集中したコードは単一性が高いので再利用製が高い
  • 新しい哲学
    • V.1にするにあたり買えなければいけないのは我々の哲学だ
    • すべてはサービスになる
    • プロジェクトやアプリケーションのコンセプトはサービスの独立性を破壊することが開発者の経験上わかっている
    • サービス単位が最上位の組織ユニットになる
    • Serverlessなサービス
      • SOAみたい
      • 組織もサービスと同じ形にすれば独立性が保たれる
      • 1つ以上の関連ファンクションというのはある（ワークフローのような）
      • CFnのように1つのリソーススタックとして扱うというのも手
  • Serverlessなサービス 対 複雑性
    • 最小限の設定
      • 設定ファイルのエレガントさがフレームワークのビジネスのキモだ
      • 1つの設定ファイルだけで管理できないといけない
      • serverless.yml
    • 最小限のスキャフォールド
      • 1フォルダ
    • コンセプトは明確
    • よりよく安全なデプロイ方法
  • Serverlessなサービス 対 フレキシビリティ
    • コードのパターン
      • ナノサービス
      • マイクロサービス
      • ニューモノリシック(グラフAPI)
      • それらのミックス
    • 多くの人が言語のベストプラクティスにならったコードをコンテナ化するが、パフォーマンスの最適化やデバッグも自分たちでやっている
    • Serverlessなサービスはコードを隠蔽するが、開発者にとってはコンテナのほうが自由に扱いやすい

LT

色々なトピックでLTがありました。まずはじめにサーバーレスでGraphQLを動作させるLTがありましたが、資料が見当たらないのでGitHubと別で話したらしい動画置いておきます。

github.com www.youtube.com

その他は以下のとおりです。

Serverless Adventures with AWS Lambda and Clojure

www.slideshare.net

What We Learned in 18 Serverless Months at Nordstrom

www.slideshare.net

Building Better Lambda Apps with Serverless

www.slideshare.net

What I Wish I'd Known Last Year

www.slideshare.net

パネルおよびラップアップ

  • 以下のメンバーによるサーバーレスに関するパネル
    • Austen Collins, Eric Windisch, Leo Anthias, Gen Ashley, Chris Gaun, and Ashley Williams
  • ラップアップ
    • A Cloud Guruのメンバーが一気に形にしたこのイベント。今後もっとコミュニティとして盛り上げて行こうね、という文脈で、（休み時間に主催者と立ち話をして日本開催は決めていたので）、日本でもさっそく開催することになったよという告知とともに、自分のことを紹介してもらいました。

ServerlessConf 日本開催

ということで日本開催、「開催する」ということだけは決まりました。いろいろ調整して、出来る限り早い時期に開催をしたいなと思っています。アップデートがあればここかツイッターかFacebookあたりで告知することになるかな、と思います。

サーバーレスアプリケーションの運用について考えたいこと

AWS Serverless

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

ひとつ前のブログエントリーを読んでいただくと、サーバーレスコンピューティングプラットフォームを提供する「ベンダーの哲学」や、サーバーレスアプリケーションを運用する「ユーザーのベストプラクティス」が参考になったと思います。

yoshidashingo.hatenablog.com

ここでは今日現在サーバーレスアプリケーションの運用について考えたいことをメモっておきます。 さまざまな立場の人からご意見をいただけると助かります。

  • 1. 新しいアプリケーションを作るときに、今まで慣れたものではなく、少々痛みを伴っても新しいアーキテクチャを組織的に試してみようと思う基準は何でしょうか？

  • 2. サーバーレスアプリケーションを実装するにあたり、利用するサービスの技術詳細（公開情報もあれば、非公開情報もあるかもしれません）を、エンジニアとして知っておくべきだと思いますか？

  • 3. (もしも)認証に利用しているサービスがなんらかの理由でダウンしてアプリケーションの利用ができなくなった場合、責任は誰にあると思いますか？

    • GitHubだったらどうでしょう？また、S3のようなストレージだったら？

  • 4.アプリケーションのアーキテクチャや、利用するサービスの見直しをするマイルストーンをどう設定しますか？（あるいはどういう状態をトリガにしますか？）

    • 四半期ごと？いつでも自由に？エンジニアが増えたら見直す？

  • 5. アプリケーションを構成する一部のサービスがダウンした場合に、縮退して継続可能なアプリケーションを設計しているとき、サービスレベル項目はどう設計しておくのがよいでしょうか？

    • API(マイクロサービス)ごと？サイトごと？両方？

5つほど上げてみましたが「サーバーレス」に限定された話でもなく、SaaSを利用するうえでのベストプラクティスだったり、マイクロサービスの文脈などから考えてみるのも面白そうじゃないでしょうか。