先週のAWS関連ブログ 〜7/4(月)

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

先日はてな東京オフィスに伺い、CTO田中さんやMackerelチームの杉山さんたちにまかないランチをごちそうになり、「なるほど、これなら絶対健康になるな」と実感しました。福利厚生をお考えの会社さんは採用をオススメします。

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

AWS公式

6月にあったアップデートをまとめて紹介します。

1. Amazon EMR 4.7.0 – Apache TezとPhoenix, 既存アプリのアップデート

• Apache Tez (0.8.3)：YARN上で動作し、YARN上のアプリケーションであるHive(SQL)やPig(Script)、MapReduce(バッチ)用のフレームワークをライブラリとして提供しており、アプリケーションをあまり変えずに性能向上を行うことができるのが売り。
• Apache Phoenix (4.7.0)：HBase(NoSQL)に対してACIDなトランザクション処理が高速に（内部的に並列処理で）SQL処理ができるアプリケーション
• HBaseが1.2.1に、Mahoutが0.12.0に、Prestoが0.147にアップデート。EMRクラスタ上のアプリからRedshiftにアクセスするためのJDBCドライバを搭載。

リンク：Amazon EMR 4.7.0 – Apache TezとPhoenix, 既存アプリのアップデート | Amazon Web Services ブログ

2. AWS CodePipeline に OpsWorks とのインテグレーション機能が追加

• AWS CodePipelineでデプロイメントプロバイダにOpsWorksを指定可能になり、以下のようなサポート状況になった。

リンク：AWS CodePipeline に OpeWorks とのインテグレーション機能が追加されました | Amazon Web Services ブログ

3. Amazon RDS SQL ServerのマルチAZサポートが東京リージョンでも（ついに！）利用可能に

• SQL Serverを冗長化する場合に、東京リージョンではRDSがマルチAZサポートがないため、フェイルオーバークラスター（Enterprise Editionでのみ対応可能なOSレベルで対応するオプション）か、Standard Editionでも利用可能なクラプロやDRBDで冗長化していたが、ついにRDSがサポートしたためにバックアップ運用やホストやミドルウェアの保守が圧倒的に楽になった。
• バージョンはSQL Server 2008 R2と2012、エディションなStandardとEnterprise

リンク：Amazon RDS for SQL ServerのマルチAZサポートが東京、シドニー、サンパウロリージョンで使用可能になりました！ | Amazon Web Services ブログ

なお、EC2ではすでに最新の2016もサポート済み

リンク：Amazon EC2 Now Supports Microsoft SQL Server 2016 | AWS Partner Network (APN) Blog

4. Amazon RDS PostgreSQLでクロスリージョンリードレプリカが利用可能に

• たとえばUSリージョンで更新されたデータが、東京リージョンのリードレプリカに非同期（論理）レプリされるため、マスターに負荷なく集計処理などが可能になる。
• また、上記のUSリージョンのマスターが災害で利用不可になった場合でも、東京リージョンのリードレプリカをマスターに昇格することで事業を継続できる。

リージョン：Amazon RDS for PostgreSQLでcross-region read replicaをご利用頂けるようになりました | Amazon Web Services ブログ

5. IAMのService Last Accessed Dataでより詳細な情報が取得されるようになった

• 昨年末リリースされたIAMエンティティ(ユーザー、グループ、ロール)がAWSサービスに最後にアクセスした時刻を表示する機能「Service Last Accessed Data」に、以下の2点の情報がさらに取得されるようになった。
  • マネージドポリシーやグループに関連付けられている全てのIAMユーザーおよびロールのLast Accessed Data
  • あるIAMユーザー、ロール、グループに対して、サービスの権限を与えている全てのポリシー
• これにより、どのユーザーやロールがサービスにアクセスしたかだけでなく、そのサービスにアクセス可能なすべてのユーザーやロールがいつ最終アクセスしたか確認可能であり、不要な権限を付与してしまっている可能性を見つけることが可能に。

リンク：【AWS発表】新機能：Service Last Accessed Dataからのより詳細な情報取得 | Amazon Web Services ブログ

6. Amazon RDS Oracleアップデート

• 定期パッチセット、April 2016 Oracle Patch Set Updates (PSU)が利用可能に
• Oracle Repository Creation Utility (RCU) 12c が利用可能に（上記PSUがあたっているバージョン）

リンク：Amazon RDS for OracleでOracle Repository Creation Utility (RCU) と April PSU Patchesをご利用頂けるようになりました | Amazon Web Services ブログ

7. AWS OpsWorksがCentOSをサポート

• OpsWorksがCentOS 7をサポート

リンク：AWS OpsWorksがCentOSをサポート | Amazon Web Services ブログ

8. 暗号化された EBS スナップショットのクロスアカウントコピーが可能に

• EBSはボリューム/スナップショットともにKMSで暗号化可能であり、非暗号化スナップショットはAWSアカウント間のコピーが可能であった
• 共有元で管理されている暗号化に利用したKMSのキーとは別のカスタムキーで再暗号化したスナップショットとともにカスタムキーが共有先アカウントに共有され、それを用いて暗号化スナップショットからブートボリュームを作成できるため、安全な仕組みでスナップショット共有が可能

リンク：【新機能】 暗号化された EBS スナップショットのクロスアカウントコピー | Amazon Web Services ブログ

9. AWS CodePipelineで失敗したアクションのリトライが可能に

• AWS CodePipelineで主導でパイプライン全体をリスタートしたり、対策前身用の別コミットを追加で行う必要があったが、失敗したアクションからリトライできるようになった。

リンク：AWS CodePipeline で、失敗したアクションのリトライが可能に | Amazon Web Services ブログ

10. ムンバイ（インド）リージョンがオープン

• 13番目のリージョン、ムンバイがローンチ（ap-southeast-2）
• AZは2つ。エッジロケーションは3つ（ムンバイ、チェンナイ、ニュー・デリー）

リンク：新たにアジアパシフィック（ムンバイ）リージョンがオープン | Amazon Web Services ブログ

11. AWS Black Belt Online Seminarと興味深いQ&Aをピックアップ

AWSサービスの権限管理

AWS Black Belt Online Seminar AWSサービスの権限管理 from Amazon Web Services Japan

www.slideshare.net

Q10: Open AMを使ってもCloudTrailでユーザを識別できますか？また、複数のアカウントや同じアカウントの複数のロールを一つのOpenAMやActive Directoryのユーザ一つで管理できますか？

A10: サードパーティ様の製品と関連いたしますので、ベストエフォートのご回答となることをご了承いただきたく思います。

Cloud Trailで表示されるFederated Userのユーザー名ですが、厳密にはIdP（Open AMやAD等）が発行したSAMLアサーションの属性値を取得して決定しています。 具体的には’https://aws.amazon.com/SAML/Attributes/RoleSessionName’という属性です。Open AM側でSAMLアサーションを生成する際にこの属性値に、例えばユーザーのメールアドレスなど組織内で一意かつ全員が必ず持っている情報を利用できればユーザーを特定することは可能です。属性の詳しい条件はこちらをご参照ください。 http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html

また一つのIdP上のユーザーを複数のAWSアカウントにマッピングすることもできます。これはAWS側でSAMLを受け取りFederated Userのロールをマップする際にAWSアカウントIDも指定する仕組のためです。複数のロールがマッピングされたユーザーは、ログインの際にどのAWS上のロールでサインインするか選択する画面が表示されます。

Elastic Load Balancing

AWS Black Belt Online Seminar Elastic Load Balancing from Amazon Web Services Japan

www.slideshare.net

Q4. ディレクトリ名を利用した振り分けは出来ないでしょうか？ A4. 現時点では対応しておりません。

Q7. 瞬間的に急増した際に５０３が返るとありましたが、TPSの目安はありますか？ A7. TPS の目安はありませんが、一般的に 5分間に 50% 以上トラフィックが増加する場合は、ご注意ください。

Q8. 正規表現などルールベースの負荷分散への対応予定はありますか？ A8. 現時点では対応しておりません。

Q16. ELBでヘッダ情報の付与はできますでしょうか？ A16. 現時点では対応しておりません。

AWS Summit Tokyo 2016 と主要アップデートのふりかえり

Black Belt Online Seminar AWS Summit Tokyo 2016 と主要アップデートのふりかえり from Amazon Web Services Japan

www.slideshare.net

• AWS Summit Tokyo 2016と今年の主要アップデートをふりかえり
• サミット期間中の新サービス発表はなし

12. dblinkを利用して、Amazon RedshiftとRDS PostgreSQLのデータをジョインする

• MPP処理向きでOLTP処理は苦手なRedshiftの弱点を克服するために、RedshiftとRDS PostgreSQLをdblinkで接続することで、以下のような効率的な処理が可能になる
  • BIやダッシュボードからのクエリをRDS PostgreSQLのマテリアライズドビューから返し、非同期にRedshiftに対してリフレッシュする
  • パーティション単位での結合をRDS PostgreSQLでブロックレンジインデックスで処理をする
  • PL/pgSQLのユーザ定義関数（UDF）からダイナミックSQLでRedshiftにクエリする
  • Redshiftから受け取った結果セットをRDS PostgreSQLでJSONに変換するなど

aws.typepad.com

その他参考：http://blogs.aws.amazon.com/bigdata/post/Tx3RS3V80XNRJH3/Real-time-in-memory-OLTP-and-Analytics-with-Apache-Ignite-on-AWS

13. Elastic Network Adapter(ENA)

• 同一AZ内で論理的にグループ化したプレイスメントグループ内で「無料で利用できる20Gbps帯域のネットワークインタフェース」
• 現状、X1インスタンス（64 cores / 128 vCPU / 1,952 GiBメモリ/10Gbps帯域）にのみ利用可能

リンク：Elastic Network Adapter – High Performance Network Interface for Amazon EC2 | AWS News Blog リンク：EC2 インスタンス向けの次世代ネットワークインターフェイス、Elastic Network Adapter (ENA) を導入

14. Amazon EFS(Elastic File System)が3リージョンで一般利用可能に

• NFS(v4.0か4.1)で複数のEC2からマウント可能なEFSが「US East (Northern Virginia)」「US West (Oregon)」「Europe (Ireland)」で一般(商用)利用可能になった
• EFSには「General Purpose」と「Max I/O」の2つのモードが指定可能
• US East (Northern Virginia)で$0.30/GB/月ということでだいぶ安い

リンク：Amazon Elastic File System – Production-Ready in Three Regions | AWS News Blog リンク：Amazon Elastic File System (Amazon EFS) の一般提供開始 リンク：【プレスリリース】Amazon Web Services、 Amazon Elastic File Systemの提供を開始

15. Amazon SNSからのSMS送信が世界対応（もちろん日本の電話番号にも）

• 送信元のリージョンが拡張された（東京リージョンも含む）
• 世界中の電話番号（日本も含む）に送信可能に

リンク：New – Worldwide Delivery of Amazon SNS Messages via SMS | AWS News Blog リンク：Amazon SNS にワールドワイド SMS を追加

16. AWS Quick Start for Docker Datacenter (DDC)

• クラスタ管理のDocker Universal Control Plane(UCP)とイメージレジストリのDocker Trusted Registry(DTR)を主要コンポーネントとする商用サポートなDocker公式ソリューション「Docker Datacenter (DDC)」のデプロイ方法やリファレンスアーキテクチャをまとめたクイックスタート(PDF)を公開

リンク：AWS Quick Start for Docker Datacenter (DDC) | AWS Partner Network (APN) Blog

17. Spotinstを使って高可用なウェブサービスをデプロイする方法

• Spotinstというサービスを使ってスポットインスタンスの管理を行う方法を説明

リンク：How to Deploy a High Availability Web Service on AWS Using Spotinst | AWS Partner Network (APN) Blog

18. 以下はその他取り上げられていた良さげなエントリ

AirtimeはECSを用いてモノリスからマイクロサービスに完全オーバーホール

https://techblog.airtime.com/microservice-continuous-integration-made-easy-with-aws-ecs-10d470e31af0#.qdib1fdqttechblog.airtime.com

API GatewayとLambdaのエラーハンドリングパターン

Error Handling Patterns in Amazon API Gateway and AWS Lambda | AWS Compute Blog

5分でLambdaにチャットボットをデプロイする

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

AWS関連

19. AWSのオートスケールとなかよく付き合う

• 実際に大規模に運用しているスケーリングポリシーは参考になる

speakerdeck.com

1台落ちたぐらいでくよくよしない

20. Amazon Kinesis + socket.io + D3.jsを使った webブラウザで行うリアルタイム可視化の仕組み

• TwitterのストリームデータをKinesisで受け取ってLambdaでつないでSNS→Socket.ioでブラウザ上のD3.jsでリアルタイム可視化する話

speakerdeck.com

その他

21. Monitorama 2016

• モニタリングのカンファレンス Monitorama が今年も開催された。

Monitorama Conference

blog.librato.com

WordCamp Europeに参加した〜SaaSify、そして第3の波：Serverless

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

ウィーンからこんばんわ、WordCamp EUのContributor Dayのクロージングを聞きながら執筆しています。昨日までの炎天下に比べて10度近く気温が下がったおかげで快適に過ごせています。

今回6/24〜26にオーストリアのウィーンで開催されたWordCamp EUに参加しました。

2016.europe.wordcamp.org

経緯

AMIMOTOという、AWS MarketplaceでWordPressのAMIを販売したり、それを使ったマネージドホスティングを提供しているDigitalcubeさんに「WordPressのユーザー層かつAWSを知らない層かつ、EUでは無名状態のAMIMOTOを広げる為に、第3者目線で問題点の洗い出しを、吉田さんの経験とセクションナインの業務コンサルとして見てもらえないか」と依頼されました。

また「DigitalCubeではAMIMOTO以外にServerlessな取り組みを積極的にやっているが、それをWordPressに活かしたいと考えているので、そのあたりで第3者としての意見が欲しい」といった依頼もいただきました。

ja.amimoto-ami.com

2013年,2014年とcloudpackのエバンジェリストとしてラスベガスのre:Inventに出展した経験から、海外で売る難しさはよくわかりますし、すでにMarketplaceでグローバルにプロダクトを販売しているAMIMOTOがどうマーケットとの関係を築けているか、あるいは最近自分の中で最も熱いトピック「Serverless」に対してWordPress界隈でどんな動きがあるかな？といった点に興味があり快諾しました。

本来こういった調査レポートは内部報告のみとするものですが、良くも悪くも全て包み隠さず一般公開しても構わないとデジタルキューブさんに許可をいただいたため、他の日本発のプロダクトやサービスが海外を目指す時にも同じように抱えうる問題点や悩みに対する参考情報にしてもらえると嬉しいと思います。

22時。ミュージアムの中庭にて。

もうひとつの目的

今回はAMIMOTO以外にもう一つ、WordPressのMicroservices化について調査する目的をもって参加していました。

WordPressは現在、世界中のWebの26.5%、マーケットシェアで59.5%を獲得している世界最大のユーザー規模を持つCMSです。しかもいまだにそのシェアが増えているという状況です。

w3techs.com

ここまでシェアが伸びた理由はいくつもあるでしょうが、そのひとつに、専門的な知識がなくてもテーマやプラグインを追加するだけで見た目の変更や機能追加がすぐにできるという便利さがあったと思います。

近年ではプラグインがサンドボックスになっていないことで突かれる脆弱性や、スケーラビリティの確保の難しさが指摘されるようになり、モノリシックであることの弊害が叫ばれるようになりました。それが顕著になるくらいエコシステムのビジネスが大きくなったし、引き続き専門知識がなくても使えるということから、非常に利用者の幅が増えてきたということでしょう。

AWSのエキスパートとして、そういった課題に対して、機能単位でAPIシステムや他事業者のサービスにオフロードする「Microservices Architecture化」や「Servicefull構成（あまりいい呼び方ではないけど）」、あるいはシングルページアプリケーション(SPA)化ができないものか、あるいはすでにうまくやっているところはあるかといった現状を確認しようと思いました。

1. グローバルにモノを売るということ

ということで、まずは「AMIMOTO」の話です。

AMIMOTOブースでよかった点は、AMIMOTOのエバンジェリストの西川さんのビジネスにおけるコミュニケーション能力が非常に高かったため、正しくサービスやプロダクトの意図や開発経緯が伝わっていた点です。わざわざ書かかせてもらいたいくらい素晴らしいコミュ力でした。

日本国内のイベントの出展ブースだと顧客の課題を聞かずに製品説明をひたすら行っている人がいたりしますが、少なくともこちらのお客さんは自分たちの抱える課題や意見を積極的に話してくれたうえで、それに対して出展者がどういう解決方法を提供するか、あるいは提供しないか（スコープが違えばその段階でそれ以上のものは提供しない）といったレベルの会話ができており、とても建設的でよかったなと感じました。

ではそれ以外はどうだったかというと、正直シブかったなと言わざるを得ない場面が多かったです。他社のブースに人が殺到していても、AMIMOTOブースに人が殺到することはなく、「何のサービスかわからない」ことにより避けられてしまっていたということが明らかでした。

何のサービスかわからない

AMIMOTOと言えば、日本ではAWSとコマーケティングしたり、積極的に都内や地方に巡業して勉強会やハンズオンを開催したり、各地方でのアンバサダー・マーケティング（網元起動隊）をしたりと、いまや日本国内においてはWordPressをAWSで稼働させるという点において知らない人はモグリだと言えるレベルで成功しているといって問題ないと思います。

ただし海外での知名度ががないうえに、以下2点のような原因から顧客の背中が押せてないと感じました。

まずブースのぱっと見で何モノかわからない

ブースにいくつかメッセージが書いてありますが、文章中心で、ブースのビジュアルで「自分たちが何モノであるか」語りかけるものがありませんでした。

とくに、サービスなのか、ホスティング事業なのか、ソフトウェアなのか、という単純な違いからしてメッセージを発信できていなかったかなと思います。

ブースに人がくるためには、遠くから見てもそのサービスやプロダクトが何なのかが分かり、お客さんの抱える課題に「あれ、もしかしてあそこのサービスは〇〇な課題に対してエレガントな解決方法を知ってるかもしれない」という程度には語りかけられる必要があります。

そしてサービスの説明が長い

海外での知名度がほとんどないので、ブースの雰囲気を見て興味が湧いたお客さんがブースに内容の説明を求めにくるのですが、ソフトウェア（AMIをセルフサービスで利用）と、マネージドホスティングがあること、ソフトウェアについてはさらにモノリシックな構成のものからマイクロサービス化された構成（JINKEI）まで自由に展開できること、といった主旨を話すのに10分以上かかり、聞き終わる頃にはお客さんの中には興味が薄れてしまう場合が多くありました。

• 「チューニング済みAMIプロダクト」なのか「AWSのマネージド・サービスを駆使したブループリント」なのか「デベロッパーや顧客がインフラレベルを意識しなくてもよいフルマネージドホスティング」なのかわからない
• 上記はそれぞれ顧客にとって何を解決するから価値があるのか

象徴的なできごと：とある有名CEOからのアドバイス

ブースに来たとある有名CEOに以下のようなことを言われました。

• 何をしているサービスか分からない
  • ホスティングサービスなのかプロダクトなのかわからない
• これは誰に対して売りたいもの？
  • エンジニア？開発者？エージェント？カスタマー？
  • エンジニアにならAWSを使っているというだけで価値が分かるかもしれないけど、そうじゃなければよしなに動いていればいいと思うよ。
• そもそもインフラはAWSじゃなくてもいいと思ってるお客さんのほうが多くて、各国のドメスティックなVPSとかを使っているのがほとんどだよ、AWSが簡単にスケールできるというなら、そういうピーキーなアクセスがあるメディアにだけターゲットを絞ってやったほうがいいと思うよ
• そもそもユーザーストーリーみたいなのはある？

SaaSifyのスコープはプロダクト開発のみにかぎらない

AMIMOTOという強力なプロダクトでさえ海外だとあまりささっていないという状況を客観的に見てみると、マーケティングの重要性に気づかされます。

「一つのことをうまくやり、設定したペルソナに対して利用上の弊害を徹底的に排除する」というベストプラクティスでさえ、そばで見ているがゆえになかなか気づきにくいものだなと感じました。

そういうものがまだしっかりとしていない段階で出展することは、調査目的などの別の意図がないかぎりはかなり厳しい忸怩たる思いを持ち帰ることになるかなと思いますし、スコープを広く取るスタンスであれば、海外においては「販売代理やプロジェクトマネジメントを肩代わりしてくれるエージェンシー（広告代理店、制作会社）」が多数あるので、そちらがわとのつながりを強化する戦略なども合わせて考えてみたほうがよいだろうと思います。

AMIMOTOの価値はなにか

AMIMOTOの大きな特徴に「チューニング済みのAMIが提供される」「CFnによりスタックが管理できる」「マネージドホスティングもやっている」というのがありますが、これは機能ではあっても顧客に届ける価値ではないので、これを顧客の価値に合わせたメッセージに変える必要があります。もちろんAWS上にホストされていることすら、それ自体は価値ではありません。

現段階の顧客に対する価値を書き出してみると、以下のようになります。

• チューニング済みのWordPress環境がすぐに準備できて、無限にスケールする環境を「自分かお任せで」構築できる
• おまかせで信頼性高くホスティングをしてくれる

これだとあまり魅力的じゃない気がしませんか。

たとえばJINKEI(CFnベース)でスタックを管理するメリットは「セキュアなプラットフォーム」で「無限にスケール」して「構成のメンテナンスの手間がかからない」ことです。当然このメリットを価値を考える人を想定しようとすると「大規模なメディア」や「個人情報/クレカなど扱うコマース」に限定されてきます。ターゲット顧客が限定されてしまうならはじめから限定してしまえばよいですね。ちょっとターゲットを絞ったメッセージに変えてみましょう。また、顧客の大半はインフラエンジニアじゃないうえ、そういうエンジニアはブース以外でも出会えるので、セルフで使う人はターゲットからはずしてみましょう。顧客の中に「メディアやコマースの事業者」と「事業者から制作と運営を請け負っているエージェンシー」が含まれますが、ひとまずここらへんまでをターゲットにしてみましょう。

• 絶対に落とせない大規模メディア事業者専用プラットフォーム「AMIMOTOメディア」
  • 全世界どこからアクセスしても同一体験が可能なグローバルCDNネットワークをビルトイン
  • ノイジーネイバーに邪魔されない専用環境
  • 大量のトラフィックが来てもエラーを返さないオートスケールがビルトイン
  • SLAごとに選べるプロサービスやサポートプラン
• セキュアで高機能でスケールするコマース専用プラットフォーム「AMIMOTOコマース」
  • PCI DSS準拠可能でセキュアに個人情報やクレジットカード情報を扱えます
  • 検索機能、レコメンドエンジン、WAF、改ざん検知などコマースに必要な機能をビルトイン
  • 高機能なのに無限にスケールされる信頼性高いプラットフォーム
  • SLAごとに選べるプロサービスやサポートプラン

だいぶマシになったんじゃないですかね。

顧客から見えるものを設計する

また、AMIMOTOのユーザーは利用開始後、直接AWSにログインして操作しないといけないので、複雑な機能性で避けられがちなAWSの管理が面倒と感じない顧客以外から避けられてしまいます。また、そもそもAMIMOTOとはなにかを理解するために何を見ればいいか考えたとき、MarketplaceなのかAWSの管理画面なのかホームページなのかよく分かりません。つまり「AMIMOTOはまだ半可品」なのです。

では顧客から見えるものを統一するという意味でどんなことをすればよいでしょう。そのヒントはダッシュボードにあると感じました。

AMIMOTOを顧客やエージェンシーにセルフで使ってもらうにしても、フルマネージドで環境を提供するにしても、以下のような情報はつねに顧客が見たいタイミングで見てもらえるようにするべきです。（以下は例）

• インフラレイヤ
  • 99パーセンタイルのレスポンス時間
  • ライブラリの更新通知
  • CPUやメモリ、ディスクの利用状況
  • ドメイン/SSL管理
• WordPressレイヤ
  • ワンクリックでのWordPress環境構築
  • ユーザー管理
  • GitHubなどのリポジトリとのインテグレーション
  • 複数のステージ管理（本番/ステージ/開発）
  • 本体やテーマ、プラグインのアップデート管理
  • アドオンとしての追加機能（検索、CDN、などなど）
  • PHPログ
  • アクセシビリティの準拠度合い
  • アクティビティ（ログインや記事更新の履歴）
  • バックアップ管理
  • SEO状況
• サービス
  • プランのアップグレード
  • 支払い履歴

WordPressレイヤについては管理画面からプラグインで実装も可能ですが、JINKEIなど複雑なリソース管理が必要になると、一枚にラップするダッシュボードがないとビジネスとしての展開は難しいのではないかと感じます。

また、今回ブースを回って他社のダッシュボードの機能性を確認しましたが、それぞれ見た目もアーキテクチャも個性的だったので、以下で紹介してみたいと思います。

Pantheon

pantheon.io

• エージェンシー(制作会社)向けのホスティングサービス
  • インフラにRackspaceを利用し、その上に独自のコンテナ技術（Dockerは当初使っていたが今は独自技術に変えたらしい）を利用してWordPressのWebのコンテナ、ストレージのコンテナ、DBのコンテナを配置してスケール変更しやすくしている。
  • 利用者はダッシュボードからWordPressのサイトをワンクリックでデプロイでき、2分くらいで完了します。
  • サイト自体のインストールはそこからさらにWordPressのインストール画面に遷移して実行する。
  • GitHubとのインテグレーションやテスト環境/本番環境の管理もこのダッシュボード
• コンテナでのスタックの管理については、彼らの社内向けの別のダッシュボードを見させてもらいました。ダッシュボード上のGUI操作で、ある環境にWebのコンテナやローカルストレージのコンテナをドラッグ&ドロップして適用すると30秒程度で構成に反映されるというデモを行っており、こういう「素早いプロビジョニング」にコンテナ技術を活用し、物理リソースとリソースの割当てを切り離して管理している点が非常に上手いなと感じました。

Flywheel

getflywheel.com

• インハウスのデザイナーやフリーランサーに人気があるホスティングサービス
• インフラはDigitalOceanなので利用可能なリージョンはDOがあるところのみ
• 共有サービスとのことなので、サイトは2分くらいでできるがおそらくモノリシックなヴァーチャルホストでの構成

Stacksight

http://stacksight.io

• WordPressやDrupalサイトにおいて、ログやバックアップ、アクティビティ（管理）、SEOなどが管理できるダッシュボード

2. モノリス対API → 第3の波：サーバーレス

さてさて、話題は変わってもう一つの調査目的「モノリシックからAPIセントリックに変わっていく世界におけるWordPress自体の変化」についてですが、WordPressの作者「Matt Mullenweg」のQ&Aセッションで、今後はフロントをJavascript化してRESTful APIによりデータを取得する構成にしていこうという方向性が語られ、APIが注目のトピックだそうです。

wordpress.tv

モノリス

WordPressがモノリシックな構成であることは、簡単にセットアップできるうえ、管理画面さえ見ればなんでもできるというとても便利な利点がある反面、以下のような弊害もあります。

弊害1：水平スケールしにくい

• コンテンツの作成場所(管理画面)と配信場所が基本的に1:1で配備されている。
• テーマやプラグインなどもサーバー単位でのメンテナンスが必要である。

弊害2：プラグイン経由のセキュリティ脆弱性がサイト全体に影響を及ぼす

弊害3：モバイル対応がいまいち

• コンテンツ作成者がWordPressの管理画面にログインしないといけないため、今後よりモバイルネイティブになっていく中で、モバイルアプリでのコンテンツ作成などに対応できない。

API

上記のような課題に対応するために、すでにコミュニティでは数年間、APIの実装について議論も実装も進んでいるそうで、現状で「コアのAPI」と「APIプラグイン」が利用可能になっています。

WordPress APIs

WordPress APIs « WordPress Codex

WordPress REST API(Plugin)

ja.wordpress.org

REST API Whitepaper

また、Human Madeという会社のメンバーが中心になり、「WordPress REST APIについての考察」についてホワイトペーパーも提供されています。

github.com

日本語訳：

github.com

メリット：ヘッドレスCMSの実現

• CMSとテーマシステムを分離し、「フロントエンドとコンテンツ管理の分離」を実現することで、リッチなUI表現や複数のフロントエンド（PC、モバイル、アプリ、それ以外の可能性も）が実現可能になります。

※ https://github.com/humanmade/rest-api-white-paper より転載

• コンテンツ管理についても、管理画面を経由せず、モバイルアプリからパブリッシュしたりできるようになる。

フロントエンドとコンテンツ管理の分離についてのもう一つの選択肢「サーバーレス」

ヘッドレスCMSの実現のためのREST APIについては、「CMSの実装」としての課題解決方法ですが、ここで「フロントエンドとコンテンツ管理の分離」を目的にするのであれば、われわれにはもう一つの選択肢がすでにあることを思い出しました。それが「サーバーレスアーキテクチャ」による解決です。

Serverless WordPress = StaticPress + Static Site Hosting + CDN + More

StaticPressを用いたサーバーレスな「フロントエンドとコンテンツ管理の分離」は、CMSの実装方法による解決ではなく、アーキテクチャやエコシステムを用いて解決する「サービスフルなアプローチ」という意味で第3の選択肢です。

Shifter: The Jamstack WordPress hosting platform.

すでにたくさんのユーザーに活用されているStaticPress

StaticPressのプラグインをインストールし、静的ファイルに書き出し、Amazon S3などでStatic Site Hostingし、CDNなどに載せて配信することで、「フロントエンドとコンテンツ管理の分離」ができ、小さなパブリッシュ用の管理インスタンスを用意するだけで、WordPressを利用せずにグローバルに大規模に配信が可能になります。

モノリシック→ヘッドレスCMSほどギャップがない

• コンテンツ管理側は基本的には現状のまま、スケーラビリティを考慮する必要がない。
• 技術的に静的ファイルにしにくい「問合せフォーム」や「ユーザー認証基盤」をどの段階でGoogle FormやZopim、Auth0やCognitoに統合するかについては考慮する必要がある。
• モノリシックからヘッドレス化するための対応コストや、今まで慣れ親しんだテーマを捨てて再度フロントをJavaScriptで実装することに比べて、圧倒的に簡単に実現できる。StaticPressで書き出してCDNから配信すればよいだけだから。

その他

• サーバーレスCMSは、CMSの「コアの実装」ではなく、クラウドサービスやCDNサービスとの組合せが大前提な「アーキテクチャ」であることには注意が必要。
• 今後はこういったアーキテクチャをさらにどれだけ簡単にセットアップできて利用できるかどうかが普及の鍵になるのではないかと思う。WordCampに参加していたユーザーやエージェンシーの人からは「AWSは複雑で難しい」と何度も言われたので、インハウスのエンジニアがいない層にいかにSaaSifyして提供するかといった課題。

まとめ

ということで、AMIMOTOの調査に行って色々気づきを得たうえ旅でした。

あと昨日のLTのスライド

ヘッドレスCMSとサーバーレス from 真吾 吉田

www.slideshare.net

セクションナインでは、既存事業のSaaSify、あるいはサーバーレスアーキテクチャを用いて信頼性高く大規模なサービスを展開したい会社をクラウドエキスパートとして、マーケティングの分野まで含めて支援しています。必要に応じてご相談ください。

https://sec9.co.jpsec9.co.jp

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

どうも、セクションナイン の 吉田真吾（@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が利用可能に

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