先週のAWS関連ブログ〜9/25(日) - EMRのデータ暗号化、API GatewayやCFnのアップデートほか

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

ServerlessConf Tokyo がとうとう今週末に迫ってきました。早めに準備ができていたとは言え、本業もやりながらだとちょっと大変なものがありますね。あと2、3仕事を片づけたら今週はイベントの最終準備に追われることになりそうです。

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

AWS公式

1. AWS エンタープライズサポートの更新 – トレーニングクレジット、オペレーションレビュー、最良アーキテクチャ(Well-Architected)

AWSのサポートには以下のようにベーシック(無料)、開発者、ビジネス、エンタープライズの4種類があり、それぞれサービス内容やサポート初回応答時間の目安の厚さに違いがあります。

Compare Support Plans | Developer, Business, Enterprise On-Ramp, Enterprise | AWS Support

その最上位プラン:エンタープライズプランにおいて、以下の3つのサービスメニューが追加されることとなったそうです。

  • トレーニングクレジット:qwikLabsと組んだセルフトレーニングの500クレジット(コースにより消費クレジットが1〜15で設定されている)および追加クレジットの30%割引
  • クラウドオペレーションレビュー:アカウントマネージャー(TAM)を通じて、オペレーションに抜け漏れがないかレビューとマネジメントプロセス(具体的にどんなものかは不明)を受けることができる
  • 最良アーキテクチャ(Well-Architected)レビュー:AWS Well-Architected Frameworkを用いたレビューを受けることができます。

http://d0.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf

Are You Well-Architected? | AWS News Blog

リンク:AWS エンタープライズサポートの更新 – トレーニングクレジット、オペレーションレビュー、最良アーキテクチャ(Well-Architected) | Amazon Web Services ブログ

2. Amazon EMR に保存データと転送中データの暗号化オプションを追加

  • EMR 4.8.0または5.0.0以降のApache Spark、Apache Tez、Hadoop MapReduceで以下のストレージタイプにデータを保存する場合に保存データの暗号化とデータ転送時の暗号化に対応した。
    • EMRFS 経由で S3 に保存したデータは、SSE-S3(S3で管理された暗号化キーによるサーバーサイド暗号化)、SSE-KMS(KMS管理の暗号化キーを用いたサーバーサイド暗号化)、CSE-KMS(KMS管理の暗号化キーを用いたクライアントサイド暗号化)などに対応
    • 各ノードのローカルファイルシステムおよびHDFSクラスターのファイルシステム内はAWS KMSによる暗号化に対応
    • 転送中のデータの暗号化にはPEMなどに対応しており、PEMはZipに固めてS3に保存しそのロケーションを指定することで利用可能。

docs.aws.amazon.com

リンク:Amazon EMR に保存データと転送中データの暗号化オプションを追加 | Amazon Web Services ブログ

3. Amazon RDS for OracleでOracle UTL_MailとJuly 2016 PSU Patchesがご利用可能になりました

  • RDS for OracleでUTL_MAILパッケージを使って直接メール送信ができるようになった。
  • また利用可能な同バージョンにおいてはJuly 2016 Oracle Patch Set Updates (PSU)が配布されている。

リンク:Amazon RDS for OracleでOracle UTL_MailとJuly 2016 PSU Patchesがご利用可能になりました | Amazon Web Services ブログ

4. API Gateway のアップデート – API 開発を簡素化する新機能

  • greedyパス:/store/{proxy+}と指定すると/store配下のすべてのURLをひとつのリソースにルーティングできる
  • ANYメソッド:HTTPリクエストを個別指定する必要なく、すべてのメソッドをひとつのリソースにルーティングできる
  • Lambda 関数統合:組み込みの Lambda 統合テンプレートを利用することでHTTPリクエストを簡単に関数で直接利用できる形式にマップできるようになった
  • 上記を駆使することで、たとえば「/store/?name=hoge」といった特定のGETパラメータを埋めておいてアクセス解析に使ったり、「/location/東京/ や /location/京都/」をひとつの検索リソースをワード違いで実装することでSEO対策などに利用ができそう。

リンク:API Gateway のアップデート – API 開発を簡素化する新機能 | Amazon Web Services ブログ

5. Amazon RDS for SQL Serverがローカルタイムゾーンをサポートしました

  • RDS for SQL Serverのインスタンス作成時にローカルタイムゾーンを指定できるようになった、これはOSレベルのタイムゾーンの変更なので、date系の型によってそれぞれどういった影響を受けるか事前に検証することが推奨されている。

リンク:Amazon RDS for SQL Serverがローカルタイムゾーンをサポートしました | Amazon Web Services ブログ

6. AWS CloudFormation の更新 – YAML、クロススタック参照、簡略化された置換

  • テンプレートをYAMLで記述できるようになった。
  • 1つのスタックから値を Export して別のスタックから !ImportValue で参照することが可能になった。入れ子にしたテンプレートのOutputsを使うような方法とはまた違った変数のスコープで制御ができる。
  • 置換関数 [Fn::Sub](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-sub.html) が利用できるようになり、${変数} を評価された実際の値に置き換えることができるようになった。

リンク:AWS CloudFormation の更新 – YAML、クロススタック参照、簡略化された置換 | Amazon Web Services ブログ

※こちらも参考に

www.slideshare.net

7. Apache BigtopとAmazon EMRでカスタムアプリケーションを構築しデプロイする方法

  • コミュニティベースでメンテナンスされているHadoopコンポーネントやツールのリポジトリであるApache Bigtopを利用してEMRクラスタ上にカスタムアプリケーションを稼働させる方法の手順説明

aws.typepad.com

AWS関連

8. Linux Bastion Hosts on the AWS Cloud: Quick Start Reference Deployment

  • 以下のHTMLのリンクからクイックスタートで実際にLinuxの踏み台を起動することができるガイドとテンプレート

https://s3.amazonaws.com/quickstart-reference/linux/bastion/latest/doc/linux-bastion-hosts-on-the-aws-cloud.pdf

docs.aws.amazon.com

リンク:Linux Bastion Hosts on the AWS Cloud: Quick Start Reference Deployment

その他

9. ISUCON関連エントリー

実際のアプリケーション実行環境は見てませんがどれも参考になりました。

dsas.blog.klab.org

tagomoris.hatenablog.com

inokara.hateblo.jp

10. PythonでもPythonじゃなくても使える汎用的なMicroservice実行環境

  • 日経さんのRest Frameworkを使ったAPI環境の話と、それらを取り巻くCI/CDパイプラインの話や監視運用の話など

speakerdeck.com

11. Who Is "YOUR" Customer?

  • 自分にとっての顧客が誰かを見極めないで競合の真似とか業界の流行りとかゆるふわなことやってると、いつまでも本当に相思相愛になりたいほんとうの顧客に届きませんよ、という話。
  • マーケターに限らずエンジニアも経営者も、「顧客」を意識しないといけないすべての人がつねに胸に刻んでおきたい訓示だと思いました。

stilldayone.hatenablog.jp

12. Full Stack Fest 2016

  • CSSやReact周りで盛り上がったような面白そうなイベントがやってたようです。

www.youtube.com

13. Velocity Conference in New York 2016

  • O'Reilly主催のVelocityconfのNY版が開催されていたようで、DevOpsやServerlessなど多岐にわたる話題のセッションが行われていたようです。

www.oreilly.com

それではまた来週。

Operability in Serverless Environments (ServerlessConfセッション紹介)

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

第5弾も海外のスピーカーの紹介です。PaaS の老舗 Engine Yard で DevOpsサポートエンジニアをしている Allan Espinosa さんから、サーバーレスを活用していくための組織の話を伺ってみます。

プロフィール

  • 名前:Allan Espinosa
  • 会社名:Engine Yard
  • 役職:DevOps Support Engineer

f:id:yoshidashingo:20160925110652j:plain

Allan は Engine Yard で働き、カスタマーが Deis や Docker、Kubernetes を本番環境で利用するためのサポートをしています。以前は世界で最も巨大な CloudFoundry 環境で Chef を使ってデプロイする管理をしていました。Allan は Packt Publishing から Docker High Performance という本も出版しています。この本にはさまざまな実例や、本番環境で Docker を up して run するようなハイレベルな概念について書いてあります。

Quick Chat

---- ようこそ日本にお越しくださいました。日本でのご予定は?

親戚や家族に会うためにすでに1ヶ月ほど日本に滞在しており、ServerlessConfの数日後に日本を発つ予定です。 数年前に実際に日本に住んでいたので、その頃のなつかしい場所も訪ねています。

---- どおりで日本語が上手なわけですね。それでは ServerlessConf Tokyo でのセッション概要を教えてください

サーバーレスな環境にWebアプリケーションをホストしたとしてもオペレーションを忘れていいわけではありません。他の多くの人がサーバーレスな環境におけるオペレーションのしやすさの面で気をつけるべき点を強調されてきました。テクノロジースタックやAPIの抽象レベルが変化しても、カスタマーのためにサービスを稼働し、運用し、保守するための大原則は変わりません。

これらの考え方はサーバーレスなアプリケーションをサポートする組織にも適用されます。つまりたとえば、短期的には組織の形を変えずにサーバーレスなチームを構成することは可能ですが、そのうち技術的負債に支払いを求められるようになり、最後には元どおりになってしまっていることに気づくことでしょう。

このトークでは、私がPlatform-as-a-Serviceソリューションを稼働するバックエンドサービスチームやベンダーとして学んだ教訓を共有します。開発者への価値提案とその他の組織への価値提案はどちらも似ていることから、たくさんの類似点が見いだせることでしょう。コンウェイの法則は未だに健在で、あなたがサーバーレスなアプリケーションの構築・稼働のためのチームを作るときにきっと役に立つことでしょう。

---- ありがとうございます。それではもう少しつっこんで話を聞かせてください。まず、あなたはサーバーレスでオペレーション作業を減らすことはできるが、それでも責任(responsibilities)は自分たちで負う必要がある、つまりサービスマネジメントは忘れてはいけないと解釈しました。合ってますか?またそれはなぜでしょうか?

はい、組織においては、自分たちの顧客に対する責任(responsibilities)と保障(guarantees)が伴います。我々のサービスがダウンしたとしてそれを他人のせいにすることはできません。利用しているFaaSやサーバーレスのプロバイダーがダウンしていたとしても、われわれは顧客の期待に応える責任があります。このマインドセットはどうやってサーバーレスなアプリケーションを構築するかという点に影響します。

---- あなたはバックエンドサービスチームの一員、またベンダーの一員として得た知見を共有してくれるとのことですが、開発者とそれ以外の組織でも共通している点というのはどういうものでしょうか?

たいていの組織はサービス開発チームとバックエンドサービスチームが分離されています。これらの分断の影響で、バックエンドサービスチームが組織に付随したチームではなく顧客とは関係ないベンダーのように振る舞ってしまうことがあります。こうやってバックエンドサービスチームが組織外のものであるかのように振る舞ってしまうことで組織の管理レベルにおいてさまざまな軋轢を生んでしまうことがあるのです。

ベンダーの中には非常に厳格に「これは対応し、これは保障しない」といった明確な範囲を決めているところもあります。また、中にはカスタマーサクセス部門を持つことで、ベンダーがカスタマーのチームの一部であるかのように感じさせてくれるところもあります。

ベンダーやバックエンドサービスチームといかにコミュニケーションを取るかによって、アプリケーションの設計は影響を受けるのです。

---- 組織をもっと素早くてアジャイルな組織に変えるためにおすすめの方法はありますか?

組織の古い構造の中には変化に対する抵抗力があります。ミッションの変更や、組織全員に影響があるような状況の変化(たとえばサービスの閉鎖や企業の倒産など)によって、人々ははじめて新しいアイデアに対してオープンになり始めるのです。これは組織における継続的なプロセスです。

DevOpsや継続的デリバリーの分野には、環境を変えるリスクを和らげながらアジャイルでハイパフォーマンスな組織に変えていくためのたくさんの文化の訓練方法があります。

---- ありがとうございました。お会いできるのを楽しみにしています。

こちらこそ。 カンファレンスでみなさんにお会いできることも楽しみにしています!

まとめ

短いチャットではありましたが、サービスマネジメントにおける責任分解点の話や、組織の構造やコミュニケーション方法がアプリケーションのアーキテクチャに影響を及ぼすという話は、Microservicesの文脈においても耳にすることが多く、サーバーレスにおいても今後議論のひとつとしていきたい内容ですね。

また、実際に開発者に近い立場でサポートをしているAlanさんの知見も非常に興味深いので、当日はさらにさまざまな視点から話を聞きたいと思いますね。

それでは当日をお楽しみに。

先週のAWS関連ブログ〜9/11(日) - AuroraリーダーエンドポイントやServerless Architecture Talksなど

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

涼しくなってきましたね。先週からオフィスの椅子を入れ替え43インチ4Kモニタを配備したらだいぶ快適になりました。

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

AWS公式

1. Amazon Auroraにリーダーエンドポイントが追加されました – 負荷分散と高可用性向上 –

  • 特定のリードレプリカのエンドポイントに接続するのでなく、このリーダーエンドポイントを利用することで、接続先がマスターに昇格した場合は別のレプリカのIPに解決されたり、特定のAZに配置したレプリカが利用できなくなった場合に他のレプリカに接続されるようになったりと、アプリから透過的に利用でき、可用性や負荷分散が実現される機能です。

リンク:Amazon Auroraにリーダーエンドポイントが追加されました – 負荷分散と高可用性向上 – | Amazon Web Services ブログ

2. AWS SDK for C++がGAに

  • 数多くのバグ修正を経てAWS SDK for C++がバージョン1.0になりました。
  • NuGet経由で入手できるようになったり、セマンティックバージョニングによりマイナーアップデートによってビルドが破損しないよう担保されています。

リンク:AWS SDK for C++ – 本稼働環境で使用する準備ができました | Amazon Web Services ブログ

3. CodeDeployのデプロイを監視してCloudWatch Eventsでトリガ発行が可能に

  • CodeDeployによるデプロイイベントを監視するようになったので、デプロイなどのイベント発生時にCloudWatch Eventsからトリガを発行することが可能になりました。
  • CloudWatch Eventsは現状「Lambda」「Kinesis streams」「SQS」「SNS」「ビルトインターゲット」にトリガ発行できるので、工夫次第でさまざまな後続アクションを作成できます。

リンク:Monitor and React to Deployment Changes in AWS CodeDeploy with Amazon CloudWatch Events

4. CloudFrontがHTTP/2をサポート

  • ワンクリックでCFのディストリビューション単位にHTTP/2を追加可能になりました。

f:id:yoshidashingo:20160912121732p:plain

リンク:Amazon CloudFront now supports HTTP/2

AWS関連

5. Serverless Architecture Talks

  • 目黒のAWSにおいてGunosyさんとクラメソさん共催で「サーバーレス」に関するセミナーイベントが開催されました。
  • 実践的なセッションが多かったようです。

speakerdeck.com

speakerdeck.com

speakerdeck.com

gunosy-beer.connpass.com

http://minamo173.hatenablog.com/entry/2016/09/12/Serverless_Architecture_Talksに参加しました%E3%80%82minamo173.hatenablog.com

dev.classmethod.jp

togetter.com

6. ECS を利用したオフラインジョブの実行環境

  • クックパッドにおけるECSクラスタ上で実行されるオフラインジョブの実行環境の話です。
  • barbeque(ジョブキュー)→hako(Dockerコンテナをデプロイするヤツ)でDockerイメージをデプロイする先のECSのホストEC2が足りない場合にエラーを発生し、それを受けてAuto Scalingグループのdesired capacityを増やしてスケールアウトする仕組みを組んで使っているそうです。
  • スケールインの仕組みはジョブの種類ごとにさまざま工夫をしているようなので、統合的な仕組みがECS側に組み込まれると良さそうに思いました。

techlife.cookpad.com

その他

7. GoogleがApigeeを買収

  • APIゲートウェイツールのApigeeがGoogleに買収され、GCPに組み込まれる予定とアナウンスされています。
  • AWS API Gatewayと同じようなサービスを考慮しているものと思われます。
  • これからこの分野はKongのようなAPIのMarketplaceまでエコシステムを整備できるかどうかという感じになるのではないでしょうか。

リンク:Google Cloud Blog - News, Features and Announcements

www.publickey1.jp

jp.techcrunch.com

今週は以上です。