Amazon Web Services ブログ

AWS Marketplace 製品の料金オプション追加

AWS Marketplace は先進の ISV (独立ソフトウェアベンダー) に大いに活用されています。 ユーザーは、ハードウェアの調達やソフトウェアのインストールを行うことなく、数分のうちに製品を見つけ、購入し、使用を開始することができます。このようなスムースな配信方法によって、ISV は新たな顧客を得ると同時に、販売サイクルを短くすることもできています。ユーザーは既存の AWS アカウントを通じ、標準の AWS 請求サイクルにしたがって製品に対する支払いを行います。

AWS Marketplace へのオンボーディングプロセスの一部として、各 ISV はソフトウェアの料金を自由に決定できます。ISV は、割引のある月間利用料金や年間利用料金の設定も選択できます。従来は時間以外に基づいてライセンスされていたソフトウェアについても、ISV は AWS Marketplace に、自分で選択したディメンションでのライセンシングオプションに対応する複数のエントリを作成できます。

このモデルはさまざまなタイプのアプリケーションで効果を上げています。しかし、通常はまだ向上の余地があります。

他の料金オプション
ソフトウェアのパッケージングと料金設定については、いっそうの柔軟性を求める声が ISV から届いていました。AWS ではそれにお応えします。複数エントリを作成せずにユーザー数モデルへの拡張を希望される場合もあれば、別のディメンションでの課金を希望される場合もあります。セキュリティ製品ベンダーは、スキャン対象のホスト数に応じた課金を希望するかもしれません。分析向けの製品のベンダーであれば、処理するデータ量に応じた価格設定を望むかもしれません。

これらの選択肢を実現させるため、ISV が自社製品にとって有効なディメンション (スキャン対象ホスト数、処理データ量など) に基づいて使用量を追跡し、レポートすることが可能になりました。これらの使用量について、単位あたりの価格を設定することも可能です (1 ホストあたり 0.50 USD、1 GB あたり 0.25 USD など)。このような使用量に対する課金は、ユーザーの AWS 請求に表示されることになります。

この変更によって、AWS Marketplace の製品ラインナップがいっそう広がることになるでしょう。

新しい料金オプションの実施
自社の AWS Marketplace 製品にこの新しいモデルの料金を使用することを希望する ISV は、アプリケーションにいくらかコードを追加する必要があります。適切なディメンションにより使用量を測定し、使用量をレポートする新しい AWS API 関数を呼び出します。このデータ (測定レコード とも呼ばれる) は、使用の有無にかかわらず、1 時間に 1 回送信する必要があります。AWS Marketplace では、実行中のアプリケーションについて、そのアプリケーションが引き続き正常動作していることを確認するために、測定レコードが 1 時間に 1 回生成されることを求めます。アプリケーションからのレコード送信が停止すると、AWS では顧客に E メールを送信し、ネットワーク設定の調整を求めます。

新しい MeterUsage 関数の呼び出し例を示します。

AWSMarketplaceMetering::MeterUsage("4w1vgsrkqdkypbz43g7qkk4uz","2015-05-19T07:31:23Z", "HostsScanned", 2);

パラメーターは次のとおりです。

  1. AWS Marketplace 製品コード。
  2. ISO-8601 フォーマットのタイムスタンプ (UTC)。
  3. 使用量のディメンション。
  4. 使用量。

使用量データは、毎日および毎月のセラーレポートの一部として利用できるようになります。


この新しい料金オプションを既に利用している製品の例をいくつかご紹介します。インフラストラクチャ料金からわかるように、これらのベンダーはさまざまな興味深い (かつ適切な) ディメンションによる料金設定を選択しています。

SoftNAS Cloud NAS:

 

Aspera faspex On-Demand:

Chef Server:

Trend Micro Deep Security:

サービス開始
この新しい料金オプションは今すぐ利用できます。


Jeff

CloudWatch Metrics for Spot Fleets

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく(1台のインスタンスから何千台のインスタンスまで)費用対効果の高いキャパシティを複数プールからリソース提供します。この強力なEC2機能の詳細については、こちらのブログを参照下さい。【AWS発表】Amazon EC2 スポットフリート API – 一度のリクエストで数千台のスポットインスタンスを制御【AWS発表】Spotフリート – コンソール、フリートスケーリング、CoudFormationに対応

私は各スポットフリートを一つの集合体として考えます。フリートが起動すると、それぞれが独立したグループのEC2インスタンスとして起動します。スポット価格の変化や、フリートキャパシティの変更に伴いインスタンスの状態は変化しますが(可能な限り費用対効果を高めるよう変化)、フリート自体はその属性を保持します。

新しいスポットフリート メトリックス

スポットフリートの管理、監視、拡張性をより簡単にするために、CloudWatchに新しいスポットフリート用メトリックが追加されました。メトリックスは、複数のディメンションからアクセスできます:スポットフリート毎、スポットフリートが構成されているアベイラビリティゾーン毎、フリート内のEC2インスタンスタイプ、アベイラビリティゾーン、インスタンスタイプ等。

下記メトリックスは各スポットフリート毎に取得されます。(これらメトリックスを取得するためには、EC2詳細モニタリングを有効にする必要があります)

  • AvailableInstancePoolsCount
  • BidsSubmittedForCapacity
  • CPUUtilization
  • DiskReadBytes
  • DiskReadOps
  • DiskWriteBytes
  • DiskWriteOps
  • EligibleInstancePoolCount
  • FulfilledCapacity
  • MaxPercentCapacityAllocation
  • NetworkIn
  • NetworkOut
  • PendingCapacity
  • StatusCheckFailed
  • StatusCheckFailed_Instance
  • StatusCheckFailed_System
  • TargetCapacity
  • TerminatingCapacity

 メトリックのいくつかは、スポットフリートの入札プロセスのヒントとなるかもしれません。例えば、

  • AvailableInstancePoolsCount – スポットフリートのリクエストに含まれるインスタンス・プールの数を示します。
  • BidsSubmittedForCapacity – スポットフリート キャパシティの入札数を示します。
  • EligibleInstancePoolsCount – スポットインスタンスリクエストの対象となるインスタンスプールの数を示します。いずれか(1)スポット価格がオンデマンド価格より高い場合、または(2)入札価格がスポット価格よりも低い場合にはプールが不適用となります。
  • FulfilledCapacity – フリートキャパシティを満たす容量の合計を示します。
  • PercentCapacityAllocation – 特定ディメンションに割り当てられた容量の割合を示します。特定のインスタンスタイプに割り当てられた容量のパーセントを決定するために、インスタンスタイプと共に使用することができます。
  • PendingCapacity – ターゲットキャパシティと利用済みキャパシティの差異を示します。
  • TargetCapacity – スポットフリート内の現在要求されたターゲットキャパシティを示します。
  • TerminatingCapacity – スポットインスタンスの終了通知を受けたインスタンスのインスタンスキャパシティを示します。

これらのメトリックスは、スポットフリートの全体的なステータスとパフォーマンスを決定する手助けになります。メトリック名からも分かりますが、スポットフリート毎に消費されるディスク、CPU、およびネットワークリソースを確認することができます。また、スポットキャパシティ確保のために入札の前にどのような傾向があるかを確認することができます。それに加え、アベイラビリティゾーン、インスタンスタイプをまたいだ下記メトリックスも取得できます。

  • CPUUtilization
  • DiskReadBytes
  • DiskReadOps
  • DiskWriteBytes
  • FulfilledCapacity
  • NetworkIn
  • NetworkOut
  • StatusCheckFailed
  • StatusCheckFailed_Instance
  • StatusCheckFailed_System

これらのメトリックスを利用することでアベイラビリティゾーン、インスタンスタイプをまたいだの負荷の許容可能な分布確認をすることができます。

フリート全体の使用率を把握するためにMax、Min、またはAvgを使用しメトリックを集計することができます。一方で、2種類以上のインスタンスからなるフリートでは、Avgを使用すること自体意味がないことにもご注意ください!

利用可能

この機能はすでにご利用頂けます。

— Jeff (翻訳は酒徳が担当しました。本文はこちら:https://aws.amazon.com/jp/blogs/aws/new-cloudwatch-metrics-for-spot-fleets/)

 

週間 AWS – 2016 年 3 月 21 日

先週 AWS の世界で起こった出来事を振り返ってみましょう。

月曜日

3 月 21 日

火曜日

3 月 22 日

水曜日

3 月 23 日

木曜日

3 月 24 日

金曜日

3 月 25 日

土曜日

3 月 26 日

来週をお楽しみに。それまでは、Twitter でフォローしてください。また、RSS フィードにもご登録ください

Jeff

週間 AWS – 2016 年 3 月 14 日

週間 AWS – 2016 年 3 月 14 日

先週 AWS の世界で起こった出来事を振り返ってみましょう。

月曜日

3 月 14 日

火曜日

3 月 15 日

水曜日

3 月 16 日

木曜日

3 月 17 日

金曜日

3 月 18 日

土曜日

3 月 19 日

日曜日

3 月 20 日

重要な新規オープンソース

  • Tumbless: S3 とブラウザのみに基づくブログ作成プラットフォームです。
  • aws-amicleaner: 使用されていない古い AMI と関連スナップショットを消去します。
  • alexa-aws-administration: Amazon Echo を使用して AWS アカウントで各種管理タスクを実行することをサポートします。
  • aws-s3-zipper: S3 バケットフォルダを取得し、ストリーミング用に zip に圧縮します。
  • aws-lambda-helper: Lambda 向けヘルパーメソッドの集合です。
  • CloudSeed: AWS スタックコンポーネントのリストを記述した後、カスタムスタックを設定し作成します。
  • aws-ses-sns-dashboard: SES 通知および SNS 通知を含む Go ベースのダッシュボードです。
  • snowplow-scala-analytics-sdk: Lambda を使用して Spark で Snowplow 強化イベントを操作するための Scala SDK です。
  • StackFormation: 軽量の CloudFormation スタックマネージャです。
  • aws-keychain-util: OS X キーチェーンで AWS 認証情報を管理するコマンドラインユーティリティです。

新しい SlideShare プレゼンテーション

新しいお客様事例

  • AdiMap は、オンライン広告の費用、アプリケーションの会計情報、給与データを測定しています。AWS を使用して、AdiMap はコンピューティングリソースやハードウェアに高額の費用をかけることなく予測財務モデルを構築し、スケーラブルな財務情報を提供し、新製品を市場に投入するまでの時間を短縮しています。
  • Change.org は世界最大で最も急成長している社会変革プラットフォームです。196 か国の 1 億 2,500 万人を超えるユーザーがキャンペーンを開始し、各地域の課題や世界的な問題に対する支援を結集しています。この団体はウェブサイトとビジネスインテリジェンスクラスターに AWS を利用し、また継続的な統合とテストに APN メンバーである Solano Labs の Solano CI を利用しています。
  • Flatiron Health は、腫瘍データを収集、整理するソリューションにより、全米で癌専門クリニック 230 棟、専門医 2,200 名を達成し、癌治療を支援しています。Flatiron はソリューションを AWS に移行することで市場に投入するまでの時間を短縮し、スタートアップ企業が IT インフラストラクチャにかける必要がある時間と費用を最小限に抑えました。
  • Global Red は、デジタルチャネル全体にわたる戦略、データ、分析、実行など、ライフサイクルマーケティングを専門としています。データプラットフォームと関連アプリケーションのアーキテクチャを変更して AWS に移行することで、Global Red は新規顧客に広告用トレーディングデスクとマーケティング自動化プラットフォームを提供するのにかかる時間が 50% 短縮されました。
  • GMobi は主に新興市場の ODM や OEM に製品、サービスを販売しています。"OTA" ファームウェア更新、モバイル請求処理、広告ソフトウェア開発キットを AWS インフラストラクチャで実行することにより、GMobi は 1 億 2,000 万名のユーザーをサポートするまでに成長し、また 99.9% を超える可用性を維持しています。
  • Time Inc. は 2014 年に新しい最高技術責任者を迎え、著名なメディア企業として大きく変わることを約束しました。AWS で、Time Inc. は、豊富なツール、クラス最高の業界標準とプロトコル、コスト削減など、クラウドコンピューティングの利点を反映したセキュリティ機能を活用しています。
  • Seaco Global は、世界最大級の運送会社です。AWS を使用して SAP アプリケーションを稼働させることで、毎月のビジネスプロセスを完了するのに必要な時間は、これまでの 4 日から、わずか 1 日に短縮されました。

新しい YouTube 動画

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローしてください。また、RSS フィードにもご登録ください。

Jeff

Redshiftアップデート:COPYやVACUUMの機能向上、クラスターリサイズの速度向上等

Redshiftの新しいバージョン1.0.1040リリースについて、その新機能や修正一覧の説明とメンテナンスの予告が公開されています。

このリリースには以下の新機能が含まれています。

  1. ユーザが定義したしきい値よりも大きい比率でソート済の表は、VACUUMでソートをスキップするように
  2. COPYで条件にそったデータを挿入した場合、ソート済の領域としてマージされるように
  3. 接続ログに、SSLのバージョンとSSLサイファーが記録されるように

1.はVACUUMコマンドの機能改善です。VACUUMは不要領域の削除とソートという2つの機能を持っているのですが、すでに大半の領域がソート済の場合はソート処理自体をスキップすることでVACUUMに掛かる時間を短縮します。

デフォルトではその閾値は95%に設定されていますが、これはユーザが指定することが可能です。VACUUMコマンドが拡張されTO sort_threshold PERCENTという形で指定できます。この数値を100にした場合は(今までと同様)常にソートが実行されるようになりますし、逆に0にするとソートが行われなくなります。この新しいオプションはREINDEXやDELETE ONLY等とも併用可能です。

  • 参考)VACUUMコマンド ※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。

2. ですが、Redshiftの中では表のデータは「ソート済領域」と「非ソート済領域」に分けて管理されています。VACUUMを使ってソートされたデータはソート済領域に保存され、追加データは非ソート領域に保存されます。

今回の機能拡張では、条件を満たした場合にCOPYで追加したデータがソート済領域に追加されるようになります。その条件はマニュアルの以下のページに記載されています。

  • Loading Your Data in Sort Key Order ※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。

 条件は以下の通りで、これらを全て満たしている必要があります。

  • 表がコンパウンドソートキー(Interleaved Sort Keyではなく)を使っていて、かつソートキー列が1つのみ
  • ソートキーの列がNOT NULL
  • 表が100%ソート済か、もしくは空(から)
  • 新しく追加されるソートキー列の値が既存データよりソート順で大きい値を持つ

これは、列に常に大きい値が挿入されるようなケース、つまり時刻がソートキーになっていて、そこに追加で新しいデータを追加し続けるような表構造(時系列でデータを入れ続ける)の場合に役に立ちます。

3.は記述のままですね。STL_ CONNECTION_LOGにsslversionとsslcipherという列が追加されています。もしこのSTL表を定期的に別表やファイルにエクスポートしている場合は、クラスターバージョンが上がった途端に列が増えるのでご注意ください。

この他に、INリスト指定時にスキャン範囲を限定することで速度を向上させる機能や、クラスターリサイズ時の転送スループット向上(リサイズに掛かる時間の短縮)、Window関数利用時にORDER BY句が必須ではなくなるといった機能向上、およびバグの修正が行われています。

この新しいバージョンはこれから約2週間にかけて各リージョンにデプロイされます。適用されるとクラスターのバージョンが1.0.1040になっているはずです。

なお、すでにオレゴンリージョン(US-WEST-2)にはデプロイされていますので、新規にオレゴンでRedshiftクラスターを立ち上げると1.0.1040で起動できます。すぐに新機能を確認したい方はオレゴンで試してみてください。

下佐粉 昭(@simosako

【アップデート】 AWS IoT が Elasticsearch Service と CloudWatch に連携できるようになりました

AWS IoT のルールでデバイスが生成したデータを直接、 Amazon Elasticsearch ドメインに渡すことができるようになりました。これによってデータを分析したり、データに対してフルテキストやパラメータによる検索を実行したり、 Kibana で可視化したりすることができます。この連携によって、デバイスの特定のエラーコードをフルテキスト検索したり、デバイスのパフォーマンスをリアルタイムに近い形で視覚化するような、ユースケースをサポートします。

加えて、AWS IoT のルールによって、デバイスが生成したデータを Amazon CloudWatch に発行することができるようになりました。これによって、デバイスのメトリックスをグラフ化して見たり、アラートをセットすることができます。

これらの新しいルールをどのように利用するかについての、より詳しい情報については、AWS IoT デベロッパー ドキュメントを参照してください。または、コンソールにサインインして、ルールを試すことができます。

 

日本語への翻訳は SA福井が担当しました。原文はこちらです: https://aws.amazon.com/jp/about-aws/whats-new/2016/03/aws-iot-integrates-with-elasticsearch-service-and-cloudwatch/

 

AWS Database Migration Service (DMS)が一般公開に!利用可能リージョンも拡大

WS000009みなさんは、現在リレーショナルデータをオンプレミスのOracle, SQL Server, MySQL, MariaDB, PostgreSQLといったデータベースに保存されていますか?それらのデータをAWSクラウドに実質的なダウンタイム無しで移動させ、スケールアウト可能というメリット、効率化されたオペレーション、複数のデータストレージが用意されている環境に移行する事に興味はありませんか?

もしそうであれば、新しい AWS Database Migration Service (DMS) こそ、みなさんのためのサービスです!去年の秋に開催されたAWS re:Inventで最初の発表がなされ、すでにお客様により1,000を超えるオンプレミスのデータベースがAWSに移行されています。お客様はテラバイト級のデータベースを動かしたままクラウドに移行する事が可能になります。データベースプラットフォームを変えずに移行することも可能ですし、要件により適切な別のデータベースプラットフォームに移行することも可能です。新しいデータベースプラットフォームへの移行を、システム全体のクラウド移行とともに実施する場合は、AWS Schema Conversion Tool がみなさんのスキーマやストアドプロシージャを新しいプラットフォーム用に変換する事をお手伝いします。

AWS Database Migration ServiceはレプリケーションインスタンスをAWS上にセットアップすることで稼動を開始します。このインスタンスはソースデータベースからデータをアンロードし、ターゲットのデータベースにロードします。これは”on-going replicaion”をサポートしており、ダウンタイムを最小にする形でのマイグレーションをサポートします。加えて、DMSは、データ型変換や異機種間データ移動(例:OracleからAurora)といった多くの煩雑な処理を代行してくれます。このサービスはレプリケーションの状況やインスタンスをモニターしており、なにか発生した場合はユーザに通知するとともに、自動的に代替となるインスタンスをプロビジョンします。

DMSは多様なマイグレーションシナリオおよびネットワーク接続のオプションをサポートしています。1つのエンドポイント(※ソースもしくはターゲットのデータベースサーバ)はAWS上にある必要がありますが、他はオンプレミスでも、EC2上のデータベースでもRDSでもかまいません。ソースとターゲットは両方が同じVirtual Private Cloud (VPC)上にあっても良いですし、別々のVPC上でもかまいません(AWS上で稼動するデータベースを別のVPC上に移すようなケース)。オンプレミスのデータベースに対してもパブリックインターネット経由で接続するか(インターネットVPNを使うことも可能です)、AWS Direct Connectで接続することが可能です。

データベースをマイグレーションする

数クリックでマイグレーションをセットアップすることが可能です!ターゲットデータベースを作成して、データベーススキーマを移行し、データレプリケーションプロセスをセットアップし、最後にマイグレーションを実行するだけです。ターゲットデータベースがソースの内容に完全にキャッチアップできたら、あとは本番環境から利用するデータベースを切り替えるだけです。

AWS Database Migration Service コンソールを選択して、”Create Migration“をクリックします。(AWS Migration Serviceコンソールは、AWSマネジメントコンソールのデータベースのセクションに「DMS」と書かれたアイコンで表示されています)

 

コンソールにはマイグレーションプロセスのオーバービューが表示されています:

Nextをクリックして、レプリケーションインスタンス作成に必要なパラメータを入力します:

このブログポストでは、既存のVPCを選択し、”Publicly accessible”のチェックを外しています。同僚の社員が、私のためにEC2上に”オンプレミスDB”役のデータベースをセットアップしてくれているからです(訳注:オンプレミスのサーバと、VPNやDirect Connectを使わずにグローバルIP経由で接続するような場合は、ここでPublic accessibleをオンにする必要があります):

レプリケーションインスタンスが作成されると、ソース、ターゲットの両データベースのエンドポイントを指定し、”Run test“をクリックしてエンドポイントに問題なくアクセスできるかを確認します。(正直に告白すると、テストをパスするために自分のセキュリティグループ設定を何度か修正するることで時間を費やしました)

そしてマイグレーションタスクを作成します。Migration typeのところで、”migrate existing data(既存データの一括ロード)”,”migrate and then replicate(一括コピーをした後に、継続的に差分レプリケーション)”,”replicate going forward(差分レプリケーションのみ実行)”の3種類から選択が可能です。

Task Settingsをクリックすることで、追加のオプションを選択可能です(LOBというのはラージオブジェクトのことです):

マイグレーションタスクが準備完了になりました。タスクを選択してStart/Resumeボタンを押すことですぐに実行することが可能です:

実行中の状況を確認することが可能です。また表へのアクセスの統計情報(Table statistics)によって、何が起こっているのかを把握することが可能です(この図はテスト用の表を使った結果なので、あまりエキサイティングな図ではないですが):

 ここまで来たら、あとはデータの正当性をチェックし、アプリケーションを新しいエンドポイントに向けるだけです。上記は一括ロードの例ですが、継続的なレプリケーション(ongoing replication)を選択することも可能です。

AWS Database Migration Serviceは多様なオプションを提供しており、上記はあくまで少し機能を紹介したに過ぎません。例えば、特定の表だけをマイグレーションしたり、複数の異なるレプリケーションタスクを作成し、それぞれ個別に実行することも可能です。DMSのドキュメントを読まれることを強く推奨します。マイグレーションを始めて行う人向けの良いガイドになっています。

多くのデータベースを移行する必要があり、作業を自動化したい場合は、AWS Command Line Interface (CLI) もしくはDatabase Migration Service APIを利用することができます。

費用と稼動リージョン

AWS Database Migration Serviceは US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney) の各リージョンに存在します。そして本日より利用可能です!(私達は他のリージョンへの拡張を今後数ヶ月で検討しています)

Jeff;

原文:https://aws.amazon.com/jp/blogs/aws/aws-database-migration-service/

翻訳:下佐粉 昭(@simosako

 

Amazon Auroraのリードレプリカで、フェイルオーバーの順番を指定可能になりました

本日、Amazon Auroraクラスタ中のレプリカノードを昇格させる順番をご指定頂けるようになりました。この機能により、フェイルオーバ発生時のレプリカノードの昇格を扱いやすくなりました。マスターインスタンスに障害などが発生した場合、Amazon RDSは優先順位が高いレプリカノードを昇格させます。低い優先順位を指定することで昇格させたくないレプリカインスタンスをご指定頂けます。例えば、バッチや集計用途などでご利用頂いているレプリカノードに対して低い優先順位を指定することで、昇格を防ぎバッチや集計作業の影響をアプリケーションに与えることを防ぐことも可能です。

フェイルオーバの優先順位は

指定した優先度
優先度が同じレプリカが複数ある場合は、フェイルオーバ発生時のマスターインスタンスよりインスタンスサイズの大きいインスタンス
優先順位もインスタンスサイズも同じ場合は、同じ優先順位のレプリカノードから任意のレプリカノードが選択されます

さらに詳細なフェイルオーバのロジックや優先順位についてはAmazon Auroraユーザガイドをご覧ください。Amazon Auroraについてはプロダクト紹介ページをご覧ください。

— 星野 (原文はこちら)

週間 AWS – 2016 年 3 月 7 日

週間 AWS – 2016 年 3 月 7 日

先週 AWS の世界で起こった出来事を振り返ってみましょう。

月曜日

3 月 7 日

火曜日

3 月 8 日

水曜日

3 月 9 日

木曜日

3 月 10 日

金曜日

3 月 11 日

土曜日

3 月 12 日

日曜日

3 月 13 日

重要な新規オープンソース

  • sqs-to-lambda-via-lambda: Lambda を使用して Amazon SQS を Lambda に実装します。
  • akiro: Lambda のネイティブ拡張を使用して NPM パッケージを魔法のようにコンパイルします。
  • cloudwatch-to-sumo: CloudWatch から Sumo Logic にメトリックスを送信します。
  • awsam: rvm をもとにモデル化された AWS アカウントマネージャです。
  • aws-jwt-auth: WSO2 によって作成された JWT を検証するための API Gateway カスタム承認ツールです。
  • aws_mbedtls_mqtt: mbedTLS ライブラリを使用して AWS IoT に接続するためのソースコードです。
  • jaxrs-lib: Elastic Beanstalk でホストする REST API を構築するための Jersey コンポーネントおよび Hibernate コンポーネントを含みます。
  • autosignr: AWS の Puppet 証明書自動署名ツールです。
  • llama-cli: Chaos Llama という、AWS ベースのアーキテクチャの弾力性と復旧性をテストするためのツールです。
  • cfn-amibaker: CloudFormation および Lambda を使用して EC2 AMI をハードコーディングします。

新しい SlideShare プレゼンテーション

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローしてください。また、RSS フィードにもご登録ください。

Jeff

10 Lessons from 10 Years of Amazon Web Services ~ AWS10年に学ぶ10のレッスン

 

Amazon.comのCTO  Werner Vogelsが、彼のブログでこの10年のAWSの軌跡を振り返っています。
ふり返りを日本語でご紹介します。英語のブログ記事はこちらです。

——————–

AWSの革新は2006年3月14日のAmazon S3のローンチで、約10年前の出来事でした。10年前を振り返ると、低価格で予測可能なパフォーマンスにより、セキュアで、信頼性があり、拡張性が高い、構築・運用が実現できていることから、数百もの学びがあります。AWSは、世界規模でサービスを構築・運用できるパイオニアであり、これらの学びは我々のビジネスにとってとても重要です。以前も何度となくお伝えしている通り、経験だけはショートカットするする方法がない、ということです。毎月の数百万ものアクティブなお客様と共に、彼らの先にいる数億ものお客様と共に、お客様にサービスを提供しながら改善するためのまたとない環境と学ぶ機会を得ています。

みなさんと共有したいいくつかの学びをご紹介します。

1. 進化可能な仕組みを構築する

ビジネスが始まる初日から、開発していたソフトウェアは、もはやソフトウェアに非ず、ということを一年間走らせてみてわかりました。その期待値は、金額でいえば一桁、二桁も異なり、スケールの問題を解決する為のアーキテクチャの再考が必要になったものです。

 
とはいえ、世界中で24時間365日多くのシステムが我々のプラットホームで動作しているのですが、システムアップグレード時にメンテナンスによる中断を起こさないようにする形態をとることはできませんでした。我々は、サービス停止を起こさずに新たなコンポーネントを導入できるアーキテクチャを作る必要がありました。Marvin Theimer, Amazon Distinguished Engineerの彼が、Amazon S3を例えば言うならば、当初は単機エンジンだったセスナが、時間を経過するとボーイング737や747sにアップグレードされている、そして最後はエアバス380sのようだ、と冗談まがいに言っていました。成長の途中で、空中燃料補給をしながら、お客様に築かれないように飛行機を乗り換えているようだと。
 
2. 想定していないことを想定する

失敗はもたらされるもので、すべてが最後は失敗に成り立っている。ルーターからハードディスク、OSからメモリユニット、誤ったTCPパケット、一時的なエラーから、永続的な故障などがあります。これは、最高品質のハードウェアであろうが量産品であろうが、最終的な顛末は同じです。

拡張性において、さらに重要になってきます。例えば、S3が数兆回ものトランザクションを処理しているときでも、ほんのわずかな可能性でも、それは現実に起こります。このような故障のシナリオの多くは事前に予知できますが、設計や構築時点では知る由もありません。

我々は、故障が何なのかは知らずとも、自然発生で起こる故障も冗長化しカバーできる構築が必要でした。システムがもし火事にあったとしても動作し続ける構造が必要なのです。システム全体をダウンさせることなく、個々のモジュールを管理できることが重要です。我々は、システム全体のヘルスチェックを可能にするような、故障発生時の影響範囲を管理する基本的な仕組みを開発しました。

 

3. フレームワークでなくプリミティブ

ほどなくして、AWSのサービスを利用したいと考えている企業の多くは既に何らかのAWSサービスを取り組んでいると気づきました。お客様が制約を許容し、過去のIT関連のハードウェアとデータセンターの世界と決別すると、前例のない使用パターンで構築し始めるということが起こりました。そのように、お客様のニーズに合ったものを確実に届ける為に、素早く動かざるを得ない状況でした。

もっとも重要な事のひとつに、小さなサービスやツールをお客様に届けるという事で、ひとつのフレームワークを強制されるよりも、キッチンの道具のようにすべてそろっていて組み合わせるように、AWSクラウドで実現できる最適な方法を選んでいただけるような構成にしていました。この方法はお客様の成功につながりましたし、後にAWSのサービスの基本的な製品/サービスの考え方をして活用しています。

お客様がサービスを手に取り、使って構築するまで、どのような優先順位で対応すべきか予期することは難しい、ということに気付くのが重要です。最小の機能性でサービスをリリースし、お客様の要望に合わせてサービスのロードマップを作っています。

4. 自動化がカギ

サービスを構築するのと従来のソフトウェア開発でお客様に納品するのとは大きく異なります。拡張性の高いシステムを管理するには、お客様の期待する信頼性、パフォーマンス、スケーラビリティに合うようにする異なるマインドセットが必要です。できるだけ自動化を可能にし、マニュアル操作とエラーを事前に取り除く管理方法を実現するには自動化が重要なカギになります。実現するには、操作に重要となる機能を制御するAPIを構築する必要がありました。お客様にも同様に助けになることです。アプリケーションの構造を分解し、それぞれ管理用APIで、拡張可能でパフォーマンスとメンテナンス性に優れたルールを作ることができます。

5. APIは永続

アマゾンの小売りの経験から得たものでもありますが、AWSがAPI中心のビジネスになることはさらに重要です。お客様が我々のAPIを使ったシステムとアプリを構築し始めたのなら、お客様のビジネスに影響を与えるとして、APIを変更することは不可能になります。APIのデザインは非常に重要であり、正しく設計できるチャンスは一度きりだということを肝に銘じねばなりません。

6. リソースの使い方を知る

適切なサービス利用料を特定しサービスを見積もる際には、コストと運用の良いデータを手に入れることです。特に薄利多売のビジネスモデルにおいてです。AWSはコストを低減させるための努力を惜しまないため、お客様に届けるサービスも投資してもよいと思えるものであり、さらに値下げしても運用継続可能な範囲を見極め、利益を低価格という形でお客様に還元しています。

先の一例として、S3ではどの程度使用されるかパターンがわかりませんでした。ですから、ストレージとネットワークの帯域に対して主な課金を行うというように仮定しました。しばらく運用した後、リクエスト回数も同様に重要な指標だと気づきました。もしお客様がたくさんの小さなファイルを持っているとすると、ストレージと帯域は何百万件のリクエストであろうと計算しませんでした。我々は、AWSのビジネスが継続的なものになるよう、計算モデルを調整しなければなりませんでした。

7. ゼロからのセキュリティ対策

お客様をセキュリティの脅威から守ることは、運用の観点においても、提供するツールや仕組みにおいても、AWSとしては最優先すべき事項です。我々が永遠に投資をし続ける領域です。

素早く学ぶひとつのアプローチとして、最初にサービスを企画・設計する段階で、セキュリティ対策を組み込んでおくことが必須です。セキュリティの専門チームは、何かを構築してから検証するチームではありません。サービスが始まるその日からパートナーとして基本的なセキュリティが担保され強固であるか確認しています。セキュリティに関しては妥協しません。

8. 暗号化は最良の住人

暗号化はお客様にとってデータにアクセスする人に対する最大の制御方法であると言えます。10年前、暗号化のツールやサービスは使いにくく、我々のサービスにどう組み込むのがベストか検討しました。

暗号化はコンプライアンス順守の観点で、サーバーサイドの暗号化をS3で実装しました。もしあなたがデータセンターでディスクをのぞき見しようとしても、どのデータへもアクセスはできないでしょう。しかし、Amazon CloudHSMと後のAmazon Key Management Serviceを使えば、お客様は独自キーの管理とそれを使った暗号化ができるようになります。

今では、暗号化対応は新サービスには企画・設計段階で統合されています。例えば、Amazon Redshiftは、それぞれのデータブロックはデフォルトでランダムキーで暗号化され、そのキーの集合はマスターキーで再度暗号化されています。マスターキーはお客様だけが知る唯一のキーで、ビジネスデータまたは個人情報にアクセスするための復号キーとなります。

暗号化は我々のビジネスにとって優先度の高い事項です。お客様にとってより簡単に使える暗号化の手段を継続して提供し、データやお客様をより強固に守ります。

9. ネットワークの重要性

AWSは多くの異なるワークロードに対応してきました。高トランザクション処理から動画変換、高度計算処理から大量のウェブアクセスまで規模を拡大しながら対応できます。これらのワークロードはネットワークにおいては独自の要件があります。

AWSはデータセンターの構成や運用に対して独自のスキルを有しており、お客様のワークロードがいかなるものであっても、それに対応した柔軟なネットワークインフラを持っています。我々は、お客様の達成したい目標に合わせて実現することに対して、ハードウェアまで独自に構築することもいといません。つまり、とても特殊な要件に対しても実現することを可能にし、AWSのネットワークを使用すればお客様が高いセキュリティの担保と差別化が可能になります。

どのようにAWS指定のネットワークハードウェアとソフトウェアでお客様のパフォーマンス改善しているかという成功事例でいうと、仮想マシンから仮想化されたネットワーク上での負荷を分散し解決する事でした。なぜならば、ネットワークアクセスは共有リソースであり、お客様が以前ネットワークアクセスで遅延を感じたこともあるからです。シングルルートの仮想I/Oに対応したNICの開発は独自のVMのハードウェア上にある仮想化NIC実装を可能にしました。これにより遅延に関しては2倍以上高速になり、ネットワーク上の実測では10倍もの改善になっています。

10. イノベーションに制限なし

AWSは、お客様に対して幅広で深いプラットホームを実現する為、様々な機能やサービスを提供しています。しかし、AWSはインハウスで構築するサービスはそれほど多くありません。パートナーエコシステムを活用し、様々な新たな方向にプラットホームを拡張しています。

例えば、StripeというパートナーはTwilioがAWS上でビジネスができるよう支払いサービスを提供しています。お客様の多くは提供するサービスの深さに対応する為のAWS上のサービスを構築しています。Philipsは健康に関するデジタルプラットホームを健康維持のためのデータ管理に使っています。OhpenはAWS上に少額バンキング向けのプラットホームを構築しています。Eagle Genomicsはゲノム解析のプラットホームを構築しています。他にもいろいろあります。肝心なことは、AWSプラットホーム上には、制限をかけるものは何もないので、やりたい事を実現すればいいのです。「制限がない」というのは、イノベーションに向けた開放で、思いがけない多くの発明の扉を開けるでしょう。

我々が今後学んでいくことが何か楽しみにしています。AWSのお客様が10年後に達成していることもです。覚えておいてください、今日がいつでも「初日」(Day 1)であることを・・・

——————–

 

(翻訳は石橋が担当しました。)