Author: AWS Japan Staff


GameStop – ミッションクリティカルなマルチチャネルのマーケティングプラットフォームを AWS に移動

GameStop は新品および中古のビデオゲームのハードウェア、ソフトウェア、アクセサリ、家電製品、ワイヤレスサービスを販売しています。14 か国に渡る小売店は 7,000 店以上あり、同社は日々何百万人もの顧客を相手に販売、サービスを提供しています。小売店の他にもオムニチャネル戦略を導入し、世界中で 4,600万人以上のメンバーがロイヤルティプログラムに参加しています。GameStop の Justin Newcom (インターナショナルテクノロジーサービス & サポート部シニアディレクター) と Jim March (アドバンスクラウドシステムエンジニア) との対話で、ミッションクリティカルなマルチチャネルマーケティングプラットフォームを従来のホスティングから AWS に移行した方法について伺いました。GameStop のストーリーをご覧ください。

ビジネスチャレンジ
2015 年 3 月、GameStop のインターナショナルホスティングとの契約期限が近付いていたため、GameStop チームは別のホスティングソリューションがないか真剣に探し始めました。以前から知られているホスティング企業数社と AWS を含むクラウドベンダー数社に RFP (提案依頼書) を送り、その返信が届き次第、決断は明らかになったそうです。その時のことを Justin は「AWS が圧倒的に優れていました」と述べています。別のクラウドベンダーとのミーティングから戻った Jim は、AWS の資料を読み進めるうちに思っていたよりも遥かに完全性が高く洗練されているサービスであることが分かったといいます。その後、GameStop は製品そして革新的なサービスを次々と送り出していること、評判、価格に基いて AWS を利用することに決定したそうです。しかし圧倒的に優れたサービスを選んだからといっても、問題なく進行させていくには様々なことを学ぶ必要があると考えていたといいます。

AWS 導入の始まり
GameStop のテクノロジーリーダー達は AWS について学びやすい文化を築いていくことにしました。AWS を使用している他の利用者やパートナーと話し合い、優れた AWS コンサルティングパートナーを呼び、クラウド導入のスタートを切りました。そして最初に移行するのはミッションクリティカルなマルチチャネルのマーケティングプラットフォームに決定したそうです。このプラットフォームは e コマース以上のもので、カナダやヨーロッパのインストアカスタマーのアクティビティの他に、オンラインカスタマーへのサービスも管理しています。これは、顧客がレジでオンライン購入をする場合などインストアとオンラインのアクティビティを統合できるようにしています。AWS への移行は 2015 年ホリデーショッピングのシーズンまでに完了し、AWS のパフォーマンスは完璧だったそうです。GameStop にとって最初のブラックフライデーは転機だったといいます。まだ Auto Scaling を使用していませんでしたが、需要に合わせて新しい EC2 インスタンスを素早く立ち上げることができ、サイトは正常に作動し素早く応答していました。また、初期段階のその他の成功例で GameStop が重要なターニングポイントに面していることが明らかになりました。例えば当社のチームは任天堂がカナダで立ち上げる予定の Amiibo の準備を 4 時間で完了しなければならないことがありました。そしてその時も問題なくプロジェクトを完了することができました。また、6 時間限りの特別セールスプロモーションに対応するために AWS でのインフラストラクチャを構築した時もスムーズに進行し AWS の請求額は、たったの 300 USD でした。こうした初期の成功により、社内のチームは1 時間から 2 時間だけという短時間限りの「スポット」セールなど、インパクトが高く短期間のマーケティングプログラムについて検討し始めました。従来、こうしたイベントは困難かつコストがかかるものでしたが、現在では楽しいものになったと Jim は語っています。

変化の時期
最初の移行を成功させた後は、クラウドスキルを取得して経験を重ねながら IT 組織を企業のクラウドインフラストラクチャチームに変えていくことでした。この近代化に伴い、チームがアジャイルおよび DevOps プラクティスの経験を培いながら、マイクロサービスやコンテイナなどの新技術を取り入れることを確実にしました。
GameStop は JiraConfluence など最新のツールを使用し、新しいアプローチを取り入れるために上層部からの賛同を求め、いくつかのテストを実行、社内研修を行うための準備を行いました。さらに、将来大きく飛躍した企業は、このモデルを導入しているケースが多い傾向があることも分かりました。場合によってはクラウドが最新のプラクティス方法を生むこともあれば、最新のプラクティスがクラウドを生み出すこともあります。IT の変革計画が起動に乗っていく上で、チームは効率性の改善とコスト節約のために、どの面でも AWS を使用する方法を検討しています。これまでとは異なったタイプの社内 IT チームになるように、社内のパートナーシップの強化、購入上のアドバイスの提供、様々なレベルの IT に関する知識を備えたチームをサポートできるようにしていきたいと考えているそうです。コストの低下、予測可能性の上昇に成功し、現在はこれまで実行することが不可能だった革新的なソリューションの構築とデプロイを実現する立場に到達したといいます。現在、GameStop は海外の IT インフラストラクチャのリソースをまとめる方法を検討しています。こうしたリソースは米国外の「データルーム」 (データセンター以下の規模) で保管されています。AWS を開発前のシングルプラットフォームと見なし、ロケーション、ビジネスユニット、アプリケーションに渡りレプリケートできる一般的なモデルを導入しました。現在は新しいハードウェアを購入していないそうです。その代わりに耐用年数が終了したハードウェアの機能を AWS に移行し、データルームを空にしています。現在のペースで行くと、8 つのデータルームはすべて 3 年以内に空になる予定だそうです。

AWS への移行と AWS の使用
通常、GameStop のインターナショナルチームにとって移行は 2 つのステージプロセスから成り立っています。最初の段階で現状のアプリケーションをクラウドにリフト & シフトします。次の段階で効率性や管理性の改善を実現するため、リファクターや最適化を行います。AWS に移行する前、マルチチャネルチームはサードパーティを通じた IT サービスの提供が主な障害になっていることに気付いていました。AWS に移動後、関係は改善しチームが解決策に向けて協力し合えるようになりました。リファクタリングの段階で、既存のオペレーションを様々な面から検討し、既存の機能を最新の AWS とどのように置き換えることができるか決定します。これにはデータベースロジック、ネットワークアーキテクチャ、セキュリティ、バックアップ、社内メッセージ、モニタリングなども含まれます。このチームはサーバーが不要なデータ処理モデルに興味を持ち、AWS LambdaAmazon API Gateway を使用して内部サービスアーキテクチャを構築する予定です。そのため、従来の古くプロセスを行う上で柔軟性に欠けたテクノロジースタックと置換することになります。また、ストレージや解析をすべて検索可能にするため、ログやメトリックスをすべて Amazon CloudWatch にルーティングすることも計画しています。現在も移行プロセスは進行中です。EC2 インスタンスは今でも主要機能として使用されていないケースが見られます。すべてのインフラストラクチャがダイナミックかつ処分できるものにするモデルを導入し、サーバーにログインしてから行うステータスチェックや変更は稀であるようにすることを目的としています。

推奨事項
Justin と Jim に、クラウド移行を検討している組織に何かアドバイスや推奨事項を求めたところ、次の答えが返ってきました。

  • すべて自動化すること。それを予期して構築すること。
  • インフラストラクチャをコードとして扱うこと。移行することを、このプラクティスを受け入れる文化作りのチャンスと見ること。
  • 最初からすべて正しく実行すること。後で面倒になるアプリケーションを移動しないこと。シンプルに、ただクラウドに移動すること。手の届きやすいものを選び、初期予算はすでに理解していることに費やすこと。移行を修得のプロセスと見ること。ただし可能な場合はコストを節約すること。
  • 時間的制約に屈しないこと。ビジネスパートナーとコミュニケーションを図ること。誰にとってもクラウドは新しいものなので、一時的な問題はあたりまえであること。透明性を高くしオープンでいること。なぜ時間が掛かるのか説明すること。
  • リーダーシップチームと IT チームが共にこのプロセスに取り掛かっている点を理解してもらうこと。自分のマネジメントチームが必ず上層部からの賛同を得ること。

その他にも Jim は AWS Management Consoleインスタンスを作成ボタンを将来の自動化に対する一種の「技術的負債」であり、返済が必要なものであると考えていると語っていました。GameStop の IT 環境改善の実現、おめでとうございます。また、本ブログにあたり GameStop の Justin と Jim からのご協力に感謝申し上げます。

Jeff

AWS オンラインセミナー – 2016 年 7 月(太平洋時間・英語によるセミナー)

次週開催のオンラインセミナーでは、いくつものすばらしいセミナーをご用意しています。いつものように参加費は無料となりますが、満席となる可能性が高いのでお早めにご登録ください。セミナーのスケジュール (太平洋時間、各オンラインセミナーの所要時間は 1 時間となります)。

7 月 26 日

7 月 27 日

7 月 28 日

7 月 29 日

Jeff

 

EC2 Run Command のアップデート – 通知を使用したコマンド実行の監視

AWS が昨年末に EC2 Run Command を立ち上げてから、クラウドやオンプレミス環境で同機能をご利用されているお客様の様子を目にすることができ大変喜ばしく思っています。本機能のリリース直後には Linux インスタンスのサポートコマンドの管理と共有をよりパワフルに、そしてハイブリッドとクロスクラウド管理を追加しました。そして本日より、中国(北京) と アジアパシフィック (ソウル) リージョンで EC2 Run Command をご利用いただけるようになりました。AWS のお客様は、定期的に行うシステム管理タスクを自動化したりカプセル化するために EC2 Run Command を使用しています。ローカルユーザーやグループの作成、該当の Windows アップデートの検索とインストール、サービス管理やログファイルのチェックなどを行っています。こうしたお客様は EC2 Run Command を基本的な構成要素として使用しているため、実際に実行するコマンドの進行状況をより把握しやすいように可視性の改善を求めています。また、各コマンドや各コードブロック実行の開始時、コマンド実行の完了時、そしてどのように完了したのかといった詳細情報を素早く取得できることを希望されています。このように非常に重要なユースケースに対応するため、コマンド内のコマンドやコードブロックで変更があった場合にステータス状況を通知できるようにしました。さらに、複数の異なる統合オプションを提供するにあたり、CloudWatch Events または SNS を通じて通知を受信できるようにしました。こうした通知により、EC2 Run Command を基本的な構成要素として使用できるようになります。コマンドをプログラムで呼び出し、結果が戻り次第プロセスを進めることができます。例えば、各インスタンスで重要なシステムファイルやメトリックスのコンテンツをキャプチャするコマンドを作成し実行することができます。コマンドが実行すると EC2 Run Command は S3 で出力を保存します。通知ハンドラーは S3 からオブジェクトを取得し、該当アイテムまたは確認が必要なアイテムをスキャンしてから不適切だと思われる点があれば通知を作成します。

Amazon SNS を使用して実行するコマンドをモニタリング

EC2 インスタンスでコマンドを実行し SNS を使用して進行状況を監視してみましょう。手順 (モニタリングコマンド) に従い、S3 バケット (jbarr-run-output)、SNS トピック (command-status)、オンインスタンスエージェントが代理で通知を送信できるようにする IAM ロール (RunCommandNotifySNS) を作成しました。SNS トピックに自分のメールアドレスを追加し、コマンドを入力しました。

次にバケット、トピック、ロール (Run a command ページの下方にあります) を特定しました。

すべてのステータス変更 (進行状況、成功、タイムアウト、キャンセル、失敗など) の通知を受信できるようにすべてを選択しました。各インスタンスのステータスに関する通知も届くように呼び出しも選択しました。呼び出しの代わりにコマンドを選択してコマンドレベルで通知を受信する方法もあります。実行をクリックしたら、選択した各インスタンスでコマンドが実行され次第、一連のメールが届きました。サンプルは次をご覧ください。

実際の環境では、通知の受信とプロセスはプログラムで行います。

CloudWatch Events を使用して実行するコマンドをモニタリング
CloudWatch Events を使用してコマンド実行を監視することもできます。SQS キューの AWS Lambda 関数もしくは AWS Kinesis ストリームに通知を送信することもできます。分かりやすく説明するため、この例では非常にシンプルな Lambda 関数を使用しました。

Run Command が発行するすべての通知の関数すべてを呼び出すルールを作成しました (下記を見ればお分かりのように必要に応じてさらに具体的なものにすることもできます)。

ルールを保存してから別のコマンドを実行し、数秒後に CloudWatch のメトリックスを確認しました。

CloudWatch のログも確認しコードの出力も検査しました。

 

今すぐご利用いただけます
この機能は本日よりご利用可能になりました。SNS を使用したモニタリングは アジアパシフィック (ムンバイ) と AWS GovCloud (US) を除くすべての AWS リージョンでお使いいただけます。CloudWach Events からのモニタリングは アジアパシフィック (ムンバイ)、中国(北京)、AWS GovCloud (US) を除くすべての AWS リージョンでご利用いただけます。

Jeff

 

新しい AWS トレーニングブートキャンプに参加して技術スキルを向上

同僚の Janna Pellegrino が次のゲスト投稿で新しい AWS トレーニングブートキャンプについて紹介しています、ぜひご覧ください。


Jeff


AWS トレーニングのポートフォリオの中から AWS のテクニカルブートキャンプでもっとも人気のある re:Invent、Summits などから 4 種類のコースをご用意しました。ご自分のスケジュールに適したコースをお選びください。

  • Taking AWS Operations to the Next Level では AWS CloudFormation、Chef、AWS SDK を活用してプロビジョニングの自動化や AWS インフラストラクチャリソースやアプリケーション設定についてご説明します。また、AWS Service Catalog の使用方法についても解説します。このコースはソリューションアーキテクトやシステム運用管理者 (SysOps アドミニストレーター) の方を対象にデザインされています。
  • Securing Next-Gen Applications at Cloud Scale では DevSecOps のアプローチを利用して、次世代のワークロードに対応できるクラウド規模の堅牢なセキュリティコントロールの設計と構成方法についてご説明します。AWS プラットフォームで高保証ワークロードを運用する場合の設計上の考慮事項も取り上げます。また、ガバナンス、構成管理、信頼性の高い決定の自動化、監査アーティファクトの生成、およびこれらのタスクをカスタムソフトウェアのワークロードでネイティブに統合する方法についてご説明するラボも実施します。このコースはセキュリティエンジニア、開発者、ソリューションアーキテクトおよびその他の技術的なセキュリティの実践者の方を対象にデザインされています。
  • Running Container-Enabled Microservices on AWS は Amazon ECS を使用してコンテナ対応アプリケーションを管理し拡張する方法についてご説明します。
    ラボでは Amazon ECS を使用して長期間実行するサービスの対応やコンテナイメージの作成とデプロイ、サービスのまとめかた、デマンドに応えられるスケールを備える方法を解説します。このコースは開発者、ソリューションアーキテクト、システム管理者の方を対象にデザインされています。
  • Building a Recommendation Engine on AWS では Amazon Elasticsearch Service、Amazon DynamoDB、DynamoDB Streams、Amazon API Gateway、AWS Lambda、Amazon S3 を使用して、リアルタイム分析や地理空間検索アプリケーションの構築方法をご説明します。Amazon Machine Learning を使って作成したモデルから生成される情報を表示する実際のロケーション認識ソーシャルアプリケーションについてもご説明します。さらに、このコースでは Lambda のデータ処理パターンや、Swagger、Grunt、AWS SDK などを使用した開発プロセスの自動化など、データを処理、分析するためのベストプラクティスについても取り上げます。このコースは開発者、ソリューションアーキテクト、データサイエンティストの方を対象にデザインされています。

Janna Pellegrino、AWS トレーニング & 認定

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

Amazon ECSでは、コンテナから簡単にAPIリクエストを行うために、Amazon EC2のIAMロールをいつでも使うことができます。これによって、AWSの認証情報をコードや設定ファイルに保存しないというAWSのベストプラクティスに従うことができる上に。鍵の自動ローテーションといった利点も得られます。

例えば、ECSとAmazon S3を使った秘匿情報管理システムを作ったり、Amazon DynamoDBを使って状態管理したり、S3を使ってコンテナによって生成された成果物を保存したり、ということがロールによって可能であり、全てにおいてAWSの認証情報をコードの中に全く持つ必要がありません。

今までは、Amazon EC2のIAMロールを使う必要がありました。つまり、ECSクラスタのEC2インスタンスに紐付いたIAMポリシーは同一クラスタ内で実行されるタスクが必要な全てのIAMポリシーを含んでいる必要がありました。これは、もし1つのコンテナが特定のS3バケットへのアクセスが必要で、他のコンテナがDynamoDBテーブルへのアクセスが必要であった時、同一のEC2インスタンスに両方のIAM権限を与える必要があることを意味しています。

新しく公開されたECSタスクのためのIAMロールの導入によって、EC2コンテナインスタンスではなくECSタスクに直接IAMロールを紐付けることで、基盤をより安全に保つことができます。この手法によって、1つのタスクはS3にアクセスする特定のIAMロールを使いながら他のタスクはDynamoDBテーブルへにアクセスするIAMロールを使うことができます。

この機能によって、ECSクラスタインスタンスのIAMポリシーも最小限にすることが可能です。なぜなら、ECSサービスとやり取りするために必要な2,3のIAM権限を与えるだけで良いからです。

この記事で、タスクIAMロールのセットアップを眺めてみましょう。

必要条件

もしまだであればECSクラスタを作成し、最低でも1つのEC2インスタンスをクラスタ内に起動します。EC2インスタンスを起動するとき、Container instance IAM roleとして、AmazonEC2ContainerServiceforEC2RoleポリシーがアタッチされたIAMロールを選択します。

もし既存のクラスタがあれば、ECS最適AMIの2016.03.eを使い、この機能を使うために2016年7月13日リリースかそれより新しいSDKを使います。

デモンストレーション

このデモでは、Amazon S3バケットを作成し’Hello World’ファイルをアップロードするだけの簡単なNode.jsアプリケーションを使います。アプリケーションのソースコードはaws-nodejs-sampleのGitHubレポジトリにあります。

Dockerイメージをビルドしプッシュする

ターミナルアプリケーションで、以下のコマンドを実行します:

$ git clone https://github.com/awslabs/aws-nodejs-sample

すると現在のディレクトリの下にaws-nodejs-sampleという名前のディレクトリが作られ、サンプルアプリのコードが配置されます。そのディレクトリでDockerfileというファイルを作成し、以下のテキストを貼り付け保存します。

FROM node:argon

# Create app directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

# Install app dependencies
COPY package.json /usr/src/app/
RUN npm install

# Bundle app source
COPY sample.js /usr/src/app

CMD [ "node", "sample.js" ]

イメージを保存するためにAmazon ECRにaws-nodejs-sampleという名前のレポジトリを作成します。以下のコマンドを実行してDockerイメージをビルドしECRレポジトリにプッシュします。AWSリージョンとアカウントIDを適切なものに置換してから実行して下さい。

$ docker build -t aws-nodejs-sample .

$ aws ecr get-login --region us-west-2 | sh

$ docker tag aws-nodejs-sample:latest 123456789012.dkr.ecr.us-west-2.amazonaws.com/aws-nodejs-sample:v1

$ docker push 123456789012.dkr.ecr.us-west-2.amazonaws.com/aws-nodejs-sample:v1

タスクのためのIAMロールを作成する

タスクのためのIAMロールを作成しますAWS Service Rolesとして、Amazon EC2 Container Service Task Roleを選択し、Attach Policy画面ではAmazonS3FullAccessというIAM管理ポリシーを選択します。

タスク定義を作成し、タスクを起動

サンプルアプリのためのタスク定義を作成しますConfigure via JSONを選択してJSONビルダーに切替え、以下のテキストをAWSリージョンとアカウントIDを適切な値に置換しながら貼り付けます。

{
    "containerDefinitions": [
        {
            "name": "sample-app",
            "image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/aws-nodejs-sample:v1",
            "memory": 200,
            "cpu": 10,
            "essential": true,
            "portMappings": []      
        }
    ],
    "volumes": [],
    "family": "aws-nodejs-sample"
}

Task Roleには、先ほど作成したIAMロールを選択し、Createを選択してタスク定義を作成します。

Task Definitionのページで、今作成したaws-nodejs-sample:1のような名前のリビジョンを選択し、ActionsからRun Taskを選択します。リストからECSクラスタを選択し、次の画面でRun Taskを選択してECSクラスタ上にタスクを起動します。

Amazon S3コンソールを開いてバケットが作成されhello_world.txtというファイルが含まれていることを確認します。バケットの名前はnode-sdk-sample-UUIDという形式になっています。

注意: 予期せぬ課金を避けるためには、上記の例で作成された、S3バケットを空にしてから削除しEC2インスタンスを削除しておきます。

まとめ

以上の例でお分かりのように、IAMの使い方やタスクには必要最低限の権限だけを与えるというAWSベストプラクティスに従うのが簡単になっています。それによって、他のタスクがアクセスできることを意図していないデータにアクセスしてしまうリスクを最小化することができます。

これはさらにECSクラスタ管理も簡潔にしてくれ、同じクラスタインスタンス上にタスクを同居させるための自由をもっと高めてくれます。注意点としてセキュリティグループは依然としてインスタンス単位で管理する必要がありますが、IAMポリシーの作成や紐付けについてはきめ細かく行うことができます。

タスクIAMロールの詳細はECSドキュメントをご覧下さい。質問や意見がございましたら、以下のコメント欄をご利用下さい。

原文: Help Secure Container-Enabled Applications with IAM Roles for ECS Tasks (翻訳: SA岩永)

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

私の同僚である Eric Fitzgerald による次の記事は、AWS Lambda 関数を使用して Amazon Inspector による評価結果をお客様のチケット発行システムやワークフローシステムに転送する方法についてご説明しています。


Jeff


AWS Re:Invent 2015 にて、セキュリティ脆弱性評価サービスの Amazon Inspector をご紹介しました。同サービスは、お客様が早期かつ頻繁にセキュリティ脆弱性テストを実施できるようにサポートするものです。Amazon Inspector をご利用いただくと、お客様は開発環境、テスト環境、実稼働環境でセキュリティテストを自動化することができます。セキュリティ脆弱性をソフトウェア開発、デプロイ、運用ライフサイクル全体の一部として識別します。Amazon Inspector の自動セキュリティテストは、お客様から非常に高く評価されています。Amazon InspectorAnalyze Application Security により、セキュリティ評価を今まで以上に頻繁に実行できるようになったほか、以前に比べセキュリティ脆弱性の早期発見に繋がったと報告を受けています。けれども、セキュリティ脆弱性を識別するだけでは完全といえません。脆弱性を発見したら問題を修正する必要があります。多くのお客様は Amazon Inspector による評価結果に対応するためのワークフローを自動化そして加速するために、Amazon Inspector を自社のワークフローシステムやチケット発行システムと統合しています。Amazon Inspector はそうしたポイントを念頭にを設計しているので、Amazon Inspector による評価結果をメールやワークフローシステムまたはチケット発行システムで統合する方法のひとつを詳しくご説明することにいたしました。

AWS Lambda を使用して Amazon Inspector による評価結果をチケット発行システムにプッシュする
この例では AWS Lambda 関数を使用して、メール経由で作成するインシデントに対応できるシステムに Amazon Inspector を接続します。イベントのフローは次のとおりです。

  1. Amazon Inspector が実行しセキュリティ評価を行います。実行終了前に Amazon Simple Notification Service (SNS) トピックへメッセージを送信します。
  2. SNS メッセージが Lambda 関数を呼び出します。
  3. 関数がセキュリティ評価から結果を取得します。
  4. 別の SNS トピックを使用してフォーマットした評価結果をメールで送信します。

途中、この関数は宛先トピックを作成し、必要であればサブスクリプションをメールで送信します。

関数を設定する
Amazon Inspector からの評価を実行する AWS リージョンで、この関数を設定してください。複数のリージョンで Amazon Inspector を実行している場合は、各リージョンで同じステップを繰り返してください。ステップは次のとおりです。

  1. Amazon Inspector の SNS トピックを作成します。
  2. Amazon Inspector を設定して、新しく作成したトピックに評価結果を送信します。
  3. 評価結果を取得、フォーマット、メールで送信できるように Lambda 関数を設定します。

SNS トピックを設定する
まず、新しい結果報告がある場合に Amazon Inspector が通知する Amazon SNS トピックを設定します。Amazon SNS トピックがフォーマットした後、他のシステムにメールで評価結果を送信します。Amazon SNS コンソールにアクセスして新しい Amazon SNS トピックを作成します。このトピックが Amazon Inspector 通知の送信先になります。トピック名はお好きなものをお選びください。次のポリシーをトピックに指定します。トピックを選択してから [Other topic actions] をクリックし [Edit topic policy] を選択してください。アドバンスビューで既存のポリシーテキストを次のポリシーに置き換えます。

{
  "Version": "2008-10-17",
  "Id": "inspector-sns-publish-policy",
  "Statement": [
    {
      "Sid": "inspector-sns-publish-statement",
      "Effect": "Allow",
      "Principal": {
        "Service": "inspector.amazonaws.com"
      },
      "Action": "SNS:Publish",
      "Resource": "arn:aws:sns:*"
    }
  ]
}

AWS Identity and Access Management (IAM) ポリシーに詳しい方は、ポリシーの Resource の値が Amazon SNS トピックの ARN と同じになるように変更すると Amazon Inspector を制限することが可能になり、このトピックに対してのみ発行することができるので、セキュリティの視点からもこれがベストプラクティスになります。Amazon Inspector を設定する
Amazon Inspector コンソールにアクセスし、評価テンプレートのページで外部システムに送信したい評価結果の評価テンプレートを選択します。その行を展開すると SNS トピックのセクションが表示されます。Amazon SNS トピックの左側にある鉛筆アイコンをクリックすると、ドロップダウンリストから先ほど作成したばかりの Amazon SNS トピックを選択することができます。トピックを選択したら [Save] をクリックしてください。

Lambda 関数を設定する
Lambda コンソールにアクセスし SNS-message-python 設計図を使用して新しい関数を作成します。

イベントソースの SNS を選択してから、ステップ 1 で作成した SNS トピックを選びます。

関数の設定を完了するには [Next] をクリックしてください。関数の名前と説明を入力し、Python 2.7 runtime を選択して関数のサンプルコードを次のコードに置き換えます。

from __future__ import print_function
import boto3
import json
import datetime
 
sns = boto3.client('sns')
inspector = boto3.client('inspector')
 
# SNS topic - will be created if it does not already exist
SNS_TOPIC = "Inspector-Finding-Delivery"
 
# Destination email - will be subscribed to the SNS topic if not already
DEST_EMAIL_ADDR = "eric@example.com"
 
# quick function to handle datetime serialization problems
enco = lambda obj: (
    obj.isoformat()
    if isinstance(obj, datetime.datetime)
    or isinstance(obj, datetime.date)
    else None
)
 
def lambda_handler(event, context):
 
    # extract the message that Inspector sent via SNS
    message = event['Records'][0]['Sns']['Message']
 
    # get inspector notification type
    notificationType = json.loads(message)['event']
 
    # skip everything except report_finding notifications
    if notificationType != "FINDING_REPORTED":
        print('Skipping notification that is not a new finding: ' + notificationType)
        return 1
   
    # extract finding ARN
    findingArn = json.loads(message)['finding']
 
    # get finding and extract detail
    response = inspector.describe_findings(findingArns = [ findingArn ], locale='EN_US')
    print(response)
    try:
        finding = response['findings'][0]
    except OSError as err:
        print("OS error: {0}".format(err))
    except:
        print("Unexpected error:", sys.exc_info()[0])
        raise
       
    # skip uninteresting findings
    title = finding['title']
    if title == "Unsupported Operating System or Version":
        print('Skipping finding: ', title)
        return 1
       
    if title == "No potential security issues found":
        print('Skipping finding: ', title)
        return 1
   
    # get the information to send via email
    subject = title[:100] # truncate @ 100 chars, SNS subject limit
    messageBody = "Title:\n" + title + "\n\nDescription:\n" + finding['description'] + "\n\nRecommendation:\n" + finding['recommendation']
   
    # un-comment the following line to dump the entire finding as raw json
    # messageBody = json.dumps(finding, default=enco, indent=2)
 
    # create SNS topic if necessary
    response = sns.create_topic(Name = SNS_TOPIC)
    snsTopicArn = response['TopicArn']
 
    # check to see if the subscription already exists
    subscribed = False
    response = sns.list_subscriptions_by_topic( TopicArn = snsTopicArn )
 
    # iterate through subscriptions array in paginated list API call
    while True:
        for subscription in response['Subscriptions']:
            if ( subscription['Endpoint'] == DEST_EMAIL_ADDR ):
                subscribed = True
                break
       
        if 'NextToken' not in response:
            break
       
        response = sns.list_subscriptions_by_topic(
            TopicArn = snsTopicArn,
            NextToken = response['NextToken']
            )
       
    # create subscription if necessary
    if ( subscribed == False ):
        response = sns.subscribe(
            TopicArn = snsTopicArn,
            Protocol = 'email',
            Endpoint = DEST_EMAIL_ADDR
            )
 
    # publish notification to topic
    response = sns.publish(
        TopicArn = snsTopicArn,
        Message = messageBody,
        Subject = subject
        )
 
    return 0

次の [ DEST_EMAIL_ADDR ] の値を必ず編集してください。次にインシデント管理システムにインシデントを送信する時に使用するメールアドレスを入力します。オプションとして、 Amazon Inspector が評価結果を送信する時に使用する SNS トピックの名前を変更することもできます。ハンドラー関数 (lambda_function.lambda_handler) はそのままにし、関数に名前を指定します。

Role のドロップダウンリストから [*Basic execution role] を選択します。Lambda が新しいページにアクセスしたら、ポリシードキュメントを表示して代わりに次を使用してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:*:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "inspector:DescribeFindings",
                "SNS:CreateTopic",
                "SNS:Subscribe",
                "SNS:ListSubscriptionsByTopic",
                "SNS:Publish"
            ],
            "Resource": "*"
        }
    ]
}

[Allow] ボタンをクリックしロールを作成したら AWS Lambda に戻り、高度な設定はそのままにしておきます。Review ページで [Enable event source] を必ずクリックしてください。

[Create function] をクリックして関数を保存します。これでステップが完了しました。

準備完了
評価結果を別のシステムに送信する場合は、評価テンプレートに最初の Amazon SNS トピック (ここで紹介した手順で作成したもの) を追加し、新しい評価結果レポートがそのトピックに公開されるよう選択されていることを確認します。最初に評価を実行すると、Amazon Inspector が新しい評価結果について Lambda に通知します。作成した Lambda 関数が SNS トピックを作成し (まだ存在しない場合)、そのトピックに宛先のメールアドレスを受信登録して (登録されていない場合)、そのアドレスにメールで評価結果を送信します。Lambda がメールアドレスをそのトピックに受信登録する必要があった場合は、受信登録の希望を確認するためのリンクが含まれたメールが 1 件届きます。このリンクをクリックして確認すると、Amazon Inspector がそのメールアドレスに評価結果を送信します。Atlassian の Jira Service Desk に接続する手順は、非常に簡単になります。Jira ServiceDesk で、Customer Channels にアクセスします。メールを受信し、新しい問題を作成できるメールアドレスが表示されます。Lambda 関数の Python スクリプトにそのメールアドレスを入力します。このメールアドレスに Inspector から評価結果が送信されます。ServiceDesk によってこれらの問題が自動的に ServiceDesk 問題に変えられるため、ここでワークフローを管理できます。

最新情報
Amazon Inspector をご利用いただき、ありがとうございます。今後の最新情報にご期待ください。

Eric Fitzgerald、Principal Security Engineer

Elastic Network Adapter – Amazon EC2 向けの高性能パフォーマンスネットワークインターフェイス

AWS をご利用されているお客様の多くは、複数の EC2 インスタンスに渡り密結合のシステムを作成し、利用可能なすべてのネットワーク帯域幅を有効に活用されています。本日、AWS はこの非常に一般的なユースケースを対象に、今まで以上に優れたサポートを提供する Elastic Network Adapter (ENA) をリリース致しました。新しい X1 インスタンスタイプを対象とする ENA には追加費用もなく、プレイスメントグループ内で使用した場合、低レイテンシーで安定したパフォーマンスを最大 20 Gbps でご提供します。ENA のメリット
ENA は X1 インスタンスで見られる最新のプロセッサと合わせて運用できるように設計されています。こうしたプロセッサは多数の仮想 CPU (X1 の場合は 128) を含むため、ネットワークアダプターなどの共有リソースを効率的に使用することが重要です。高いスループットやパケット毎秒 (PPS) のパフォーマンスを提供しながら、ENA は数々の方法でホストプロセッサのロードを最小限に抑えます。以下の例をご覧ください。

  • チェックサム生成 – ENA はハードウェアの IPv4 ヘッダーチェックサム生成と TCP / UDP の一部のチェックサム生成を処理します。
  • マルチキューデバイスインターフェイス – ENA は複数の配信を使用し、キューを受信して内部のオーバーヘッドを削減します。
  • 受信側による実行 – ENA は適切な vCPU が処理するように着信パケットを誘導します。これにより障害を回避しキャッシュの有効性を高めることができます。

こうした機能は可能な限りプロセッサのワークロードを軽くし、ネットワークパケットと生成または処理を行う vCPU 間で短く効率的なパスを作成するために構築されています。ENA の使用
X1 インスタンス間で 20 Gbps のパフォーマンスを実現するには、プレイスメントグループから起動してください。ENA のその他のメリットは、低レイテンシーや安定したパフォーマンスをインターネットやプレイスメントグループ外からの通信においても提供することです。新しい ENA ドライバは最新の Amazon Linux AMI でご利用いただけます。また、近日中に Windows AMI にも対応する予定です。お客様自身の AMI での利用につき、ソースフォーム (Linux および Windows) でもご使用いただけます。ドライバは Intel の Data Plane Developer Kit (DPDK) を使用してパケットプロセスのパフォーマンスやスループットを高めます。ご自分で AMI を作成される場合は、 enaSupport の属性を設定してください。 コマンドラインからの作成については次をご覧ください。

$ aws ec2 modify-instance-attribute --instance-id INSTANCE_ID --ena-support true

ENA をサポートしていないインスタンスで AMI を使用することもできます。今後のプラン
上記の通り、現在 ENA は X1 でご利用いただけます。今後 EC2 インスタンスタイプでも使用可能になる予定です。

新たにアジアパシフィック(ムンバイ)リージョンがオープン

私たちはインドのムンバイに新たなリージョンをオープンしたことをお知らせ致します。インドでAWSをお使いのお客様は、サービスをより快適にお使いいただけるようになります。

新リージョン
アジアパシフィック(ムンバイ)リージョンは2つのアベイラビリティゾーンがあり、グローバル全体では35個になりました。本リージョンでは、Amazon Elastic Compute Cloud (EC2) (C4, M4, T2, D2, I2, とR3インスタンスが 利用可能)と Amazon Elastic Block Store (EBS), Amazon Virtual Private Cloud, Auto Scaling, とElastic Load Balancing などの関連サービスに対応します。

他にも以下のサービスに対応致します。

インドには3個所のエッジロケーション(ムンバイ、チェンナイ、ニュー・デリー)があります。それぞれ、Amazon Route 53, Amazon CloudFrontS3 Transfer Acceleration に対応します。AWS Direct Connectも以下のパートナー経由で利用できます。

アジアパシフィック(ムンバイ)リージョンは私たちの13番目のリージョン(AWS Global Infrastructureのマップはこちら)で、いつもの通りコンソール上のメニューで確認できます。

お客様
インドには75,000以上のアクティブなAWSのお客様がいて、様々な産業で幅広くご利用いただいています。本日のオープンにあたっては、いくつかのお客様にプレビュー公開しています。2社(Ola CabsとNDTV)はその経験と考察を十分に共有していただきました。

Ola Cabs のモバイルアプリは、インドにおける100以上の拠点間の乗り換えを再定義しました。AWSは、OLAがサービスにおいて顧客体験の提供に妥協することなく、新機能やサービスを素早くお客様に提供できるようイノベーションを継続的を支援しました。Ankit Bhati (CTOで共同創業者)は以下のように話しています。

私たちは、乗り換えの選択肢提供と利便性の提供のため、数十億のインド人が使えるモバイルアプリをAWSのテクノロジーを使って作っています。最高の顧客体験、お客様へ新機能やサービスの提供においてさらに早くイノベーションを起こすこと、その為にテクノロジーは実現の鍵です。これにより、インドで100以上もの都市と55万ものドライバーのパートナーの役に立っています。様々なAWSのビッグデータ関連のサービスを利用し、ペタバイト級の解析とディープラーニングを行い、お客様が必要な時にドライバーとすぐに近づける仕組みを提供しています。AWSなら、100もの遅延の少ないAPIにより、毎日数百万のリクエストのあるスケーラビリティの高いマイクロサービスベースのプラットフォームに対して、一日に30以上もの変更を加えることが可能になります。私たちもアジアパシフィック(ムンバイ)リージョンを試してみました。素晴らしいですし、顧客体験をさらに強化するのに役立つでしょう。

 


NDTVは、世界で数百万もの人々に視聴されている、インドで主要なメディアです。NDTVは2009年からAWSを使用しており、映像やウェブプラットフォームで利用しています。2014年5月のインド総選挙の間、NDTVは5億ヒットから130億ヒットにもなる、通常の26倍ものウェブトラフィックを投票日に予測しており(通常は40万ヒット/秒)、すべてAWS上で動作しています。Kawaljit Singh Bedi (CTO of NDTV)によると、

NDTVはインドでのプレビューにおいて、AWSインフラの信頼性や安定性に関して信頼できる結果を報告できたことをうれしく思います。技術チームが実施したインドでのテストにおいて、ネットワークの遅延が他の代替手段よりも少ないことを確信しました。昨年ウェブとモバイルのトラフィックは30%以上も増加し、e子アースやプラットフォーム連携し地域を拡大していく際にアジアパシフィック(ムンバイ)リージョンが使用できることにワクワクしています。リージョンオープン時点で提供されるサービスポートフォリオ、低遅延、素晴らしい信頼性、インド国内の規制当局の要望事項との合致など、NDTVは現状からすべてAWSへミッションクリティカルアプリとITインフラを移行することを決めました。

 

 


他にも以下のようなお客様がいらっしゃいます。

 

Tata Motors Limited インドを代表する自動車製造メーカーはテレマティクスシステムをAWS上で実現しています。車両オーナーが車両の状況を即時把握するソリューションとして使用しています。AWSはTata Motorsがイノベーションと顧客体験をさらに俊敏にできるよう支援しました。

redBus はインドを代表するウェブ、モバイル、バス会社を経由してチケットを販売するプラットフォームです。redBusは現在67,000ものルートをカバーし、バス会社は1,800にも上ります。2010年の200万から、年間4000万ものバスチケットの販売に規模が拡大しました。繁忙期には毎分100チケット以上にもなります。redBusはSaaSアプリを開発し、独自のチケットや席管理を自分で操作できる選択肢をバス会社に与えました。redBusはAWSを使ってシンガポールやペルーなど新たな地域にもグローバルに展開しています。

Hotstar は85,000時間ものドラマ、映画やスポーツイベントなどを映像ストリーミングするインド最大のプラットフォームです。2015年2月に開始し、Hotstarは最速で世界中いたるところで使われるようになったアプリのひとつです。6,800万ユーザにダウンロードされ、動画再生の高いテクノロジーとデバイスとプラットフォーム間の品質の良さで視聴者を魅了しています。

Macmillan India はインドの教育市場において120年以上もの間出版事業を展開しています。AWSを使用するにあたり、Macmillan Indiaは重要なエンタープライズのアプリケーションであるビジネスインテリジェンス(BI)、販売・流通、材料管理、財務経理、人事、CRMなどをチェンナイにあるデータセンターからAWSに移行しました。移行によりMacmillan IndiaはSAPの可用性をほぼ100%にし、インフラの設定作業を6週間から30分に短縮しました。

パートナー
インドの幅広いパートナと共に働けることをうれしく思います。いくつかご紹介します。

  • AWS プレミアコンサルティングパートナー – BlazeClan Technologies Pvt. Limited, Minjar Cloud Solutions Pvt Ltd, Wipro.
  • AWS コンサルティングパートナー – Accenture, BluePi, Cloudcover, Frontier, HCL, Powerupcloud, TCS, Wipro.
  • AWS テクノロジーパートナー – Freshdesk, Druva, Indusface, Leadsquared, Manthan, Mithi, Nucleus Software, Newgen, Ramco Systems, Sanovi, Vinculum.
  • AWS マネージドサービスプロバイダー – Progressive Infotech, Spruha Technologies.
  • AWS Direct Connect パートナー – AirTel, Colt Technology Services,  Global Cloud Xchange, GPX, Hutchison Global Communications, Sify, Tata Communications.

インドのAmazonオフィス
2011年以降インドに6つのオフィスを開設しました。デリ、ムンバイ、ハイデラーバード、バンガロール、プネ、チェンナイにあります。オフィスでは、エンタープライズ、政府機関、教育機関、中小・中堅企業、スタートアップ、開発者など幅広いカスタマーベースを支援します。

サポート
AWS Supportで準備しているサポートのすべてが対象(Basic, Developer, Business, Enterprise)です。長期契約なしに、上限なしで顧客および支払いに関するサポートをご利用いただけます。

コンプライアンス
各AWSリージョンは、ISO 27001, ISO 9001, ISO 27017, ISO 27018, SOC 1, SOC 2, and PCI DSS Level 1など現地の法律や規律に準拠するよう準備されています。AWSはサードパーティによって評価されるinformation Security Management System (ISMS)に準拠しています。これらの評価は、AWSウェブサイトや認証や監査報告書を弊社のホームページや要望によりお客様へ提供することで、幅広い要望事項に対応します。

詳しくはこちらをご覧ください。さらにAWSを学ぶにはAWS Cloud Compliance と Data Privacy FAQ をご覧ください。

使ってみましょう
アジアパシフィック(ムンバイ)リージョンがオープンし、本日からご利用いただけます!追加の情報として、移行方法のドキュメント、お客様の事例、トレーニングやイベントの情報、インドでのパートナー一覧などがこちらから参照いただけます。

私たちはインドでの販売状況を記録(AISPLとして知られています)しています。詳細についてはAISPLカスタマーアグリーメントを参照ください。

Jeff;

(翻訳は石橋が担当しました。原文はこちらです。)

 

Amazon Elastic File System が 3 つのリージョンで利用可能に

AWS のストレージ製品ラインは時間とともに豊かに多様な成長を遂げてきました。単一のストレージクラスで開始した Amazon S3 は現在、定期的かつ低頻度にアクセスされる、アーカイブ済みのオブジェクト向けの複数のストレージクラスを提供しています。同様に、単一のボリュームタイプで始まった Amazon Elastic Block Store (EBS) も、現在は 4 種類の SAN スタイルブロックストレージを提供しており、各ストレージが特定のアクセスパターンやデータタイプ向けに設計されています。オブジェクトストレージおよびブロックストレージへの対応は S3 および EBS によってカバーされていることから、AWS は次にファイルシステムに注目を向けました。AWS は、複数の EC2 インスタンス向けに、完全マネージド型ファイルシステムへの低レイテンシーの共有アクセスを提供するため、昨年 Amazon Elastic File System (EFS) を発表しました。そしてこのたび、EFS が US East (Northern Virginia)、US West (Oregon)、Europe (Ireland) の各リージョンでも本稼動使用できるようになりました。本日の発表に至るまで、AWS は長期のプレビュー期間にわたり、実に幅広いお客様のユースケースを検討してきました。EFS プレビューは、大規模かつ高スループット処理ワークロード、および多様なコンテンツとウェブ配信に最適でした。プレビュー期間、こうしたワークロードに対する EFS パフォーマンスについてポジティブなフィードバックが多数寄せられました。一方、レイテンシーの変化に影響を受け、ファイルシステムメタデータを多用するワークロードについても同様に優れたサポートを提供してほしいというご要望もいただきました。こうしたフィードバックへの取り組みの結果、本日のラウンチは非常に幅広いユースケースに対応できる設計となっています。これまで、お客様には EFS に大変ご満足いただき、すぐにでも使用を開始したいというご意見をいただいております。

EFS を構築した理由
AWS をご利用の多くのお客様から、拡張可能なファイルストレージをより簡単に管理する方法を提供してほしいというご要望をいただいてきました。こうしたお客様には、共通の名前空間と、企業または部署別のファイル階層への簡単なアクセスによってメリットを受ける、ウェブサーバ群やコンテンツ管理システムを稼動している方もいらっしゃいます。一方、多数の大規模ファイルを作成、処理、削除する HPC およびビッグデータアプリケーションを運用して、著しく変化するストレージ利用とスループットの需要に対応しているお客様もいらっしゃいます。また、AWS のお客様は、高可用性、高耐久性とともに、アクセスと変更に対しても強力な整合性を提供するモデルを求めてきました。

Amazon Elastic File System
EFS では、POSIX 準拠のファイルシステムを作成して、NFS 経由で 1 つ以上の EC2 インスタンスにアタッチできます。このファイルシステムは必要に応じて拡大/縮小するため (一定の上限はなく、ペタバイト規模まで拡張可能)、ストレージスペースや帯域幅を事前にプロビジョニングする必要はありません。料金が発生するのは、使用したストレージ分のみです。EFS は、ファイル、ディレクトリ、リンク、メタデータのコピーを複数のアベイラビリティーゾーンに保存することで、データを保護します。複数のクライアントが同時にアクセスする大規模なファイルシステムのサポートに必要なパフォーマンスを提供できるよう、Elastic File System パフォーマンスもストレージにあわせて拡張します (この点については後ほど詳しくご説明します)。それぞれの Elastic File System は 1 つの VPC からアクセス可能で、VPC 内で作成するマウントターゲットを介してアクセスされます。VPC のどのサブネットでもマウントターゲットを作成することができます。各マウントターゲットへのアクセスは、通常通りセキュリティグループを使ってコントロールされます。EFS には 2 つの異なるパフォーマンスモードがあります。1 つめのモードは、デフォルトの汎用モードです。数十、数百、数千の EC2 インスタンスがファイルシステムに同時アクセスする場合を除き、このモードを使用します。もう 1 つのモード I/O 最大は、より高レベルの集計スループットと 1 秒あたりのオペレーション数にあわせて最適化されますが、ファイルオペレーションのレイテンシーがわずかに高くなります。ほとんどの場合は汎用モードから開始し、関連する CloudWatch メトリックス (PercentIOLimit) を監視してください。汎用モードの I/O 制限のプッシュを開始する場合は、I/O 最大モードで新しいファイルシステムを作成し、ファイルを移行すれば、さらに高いスループットと 1 秒あたりのオペレーション数を活用することができます。

Elastic File System の動作
Elastic File System の作成、マウント、アクセスは非常に簡単です。私は AWS Management Console を使用しました。EFS API、AWS Command Line Interface (CLI)、またはAWS Tools for Windows PowerShell を使うオプションもあります。コンソールを開き、[Create file system] ボタンをクリックしました。

次に、VPC の 1 つを選択し、パブリックサブネットにマウントターゲットを作成しました。

私のセキュリティグループ (corp-vpc-mount-target) では、EC2 インスタンスがポート 2049 のマウントポイントにアクセスできます。以下はインバウンドルールです。アウトバウンドルールも同じです。

Name タグと Owner タグを追加し、汎用パフォーマンスモードを選択しました。

次に、情報を確認して、[Create File System] をクリックしました。

すぐにファイルシステムを使用できるようになりました (マウントターゲットもその後 1 分ほどで準備が完了しました)。

[EC2 mount instructions] をクリックし、EC2 インスタンスにファイルシステムをマウントする方法を確認しました。

ファイルシステムを /efs としてマウントすると、以下のようになりました。

多くのファイルをコピーし、しばらく NFS ステータスを確認していました。

コンソールに、ファイルシステムによる消費容量のレポートが表示されます (この情報は 1 時間ごとに収集され、収集後 2~3 時間で表示されます)。

 

CloudWatch メトリックス
各ファイルシステムは、CloudWatch に以下のメトリックスを提供します。

  • BurstCreditBalance – バーストレベルのスループットで転送可能なデータ量。
  • ClientConnections – ファイルシステムに接続されているクライアント数。
  • DataReadIOBytes – ファイルシステムから読み込まれるバイト数。
  • DataWriteIOBytes – ファイルシステムに書き込まれるバイト数。
  • MetadataIOBytes – 読み込み/書き込みされるメタデータのバイト数。
  • TotalIOBytes – 前述の 3 つのメトリックスの合計。
  • PermittedThroughput – ファイルシステムのサイズに基づいた最大許容スループット。
  • PercentIOLimit – 汎用モードで利用可能な I/O の割合。

これらのメトリックスは CloudWatch コンソールで確認できます。

 

EFS バースト、ワークロード、パフォーマンス

各 EFS ファイルシステムで可能なスループットは、ファイルシステムの拡張とともに増加します。ファイルベースのワークロードは通常スパイクが発生しやすく、短期間は高レベルのスループットが要求され、それ以外の期間は要求されるスループットのレベルが下がります。EFS は、必要に応じて高スループットレベルに対応してバーストするよう設計されています。すべてのファイルシステムは、100 MB/秒スループットまでバーストできます。1 TB を超えるファイルシステムではストレージ TB あたり 100 MB/秒までバースト可能です。例えば、2 TB のファイルシステムでは 200 MB/秒まで、10 TB のファイルシステムでは 1,000 MB/秒スループットまでバースト可能です。1 TB を超えるファイルシステムでは、使用時間の半分ファイルシステムが使われていない場合、残りの半分の時間はバーストし続けることができます。EFS ではクレジットシステムを使ってファイルシステムがバースト可能なタイミングを判断します。各ファイルシステムは、ファイルシステムのサイズに応じたベースラインレート (ストレージ 1 TB あたり 50 MB) でクレジットを蓄積し、データの読み込み/書き込み際にこれを使用します。クレジットが蓄積すると、ファイルシステムでベースラインレートを超えるスループットを利用できるようになります。実際の運用例で考えてみましょう。

  • 100 GB のファイルシステムでは 1 日 72 分まで最大 100 MB/秒のバーストが可能です。または、連続して 5 MB/秒までバーストできます。
  • 10 TB のファイルシステムでは、1 日 12 時間最大 1 GB/秒まで、または連続して 500 MB/秒バーストが可能です。

クレジットシステムの仕組みについては、ファイルシステムパフォーマンスについての EFS ドキュメントを参照してください。この機能をよく理解するために、数日間ファイルをコピーして連結してみたところ、結局 2 TB を超えるファイルシステムの容量が使用されました。ファイルコレクションが 1 TB を超えると、使用量にあわせて PermittedThroughput メトリックスも上昇することがわかりました。以下は、表示された内容です。

どのファイルシステムでも同じように、スループットはワークロードの特徴に左右されます。平均 I/O サイズ、EFS への同時接続数、ファイルアクセスのパターン (ランダム/シーケンシャル)、リクエストモデル (同期/非同期)、NFS クライアント構成、NFS クライアントを実行する EC2 インスタンスのパフォーマンス特性のそれぞれがポジティブまたはネガティブな影響を及ぼします。要約すると以下のようになります。

  • 平均 I/O サイズ – 小さいファイルに関連付けられたメタデータを NFS プロトコル経由で管理する作業、および耐久性と可用性の高いデータにするための EFS 側の作業が組み合わさって、オペレーションあたりのオーバーヘッドが作られます。一般的に、オペレーションあたりのオーバーヘッドは、より大量のデータで償却されるため、全体的なスループットは平均 I/O サイズに合わせて高まります。また、通常、読み込みにかかる時間は書き込みよりも高速です。
  • 同時接続数 – 各 EFS ファイルシステムは、数千のクライアントからの接続に対応できます。(複数の EC2 インスタンスからの) 高度に並列化された動作を実行できる環境では、多数の同時オペレーションに対応する EFS の機能が効果を発揮します。
  • リクエストモデル – マウント時間に async オプションを含めることで、ファイルシステムへの非同期書き込みを有効にすると、保留中の書き込みがインスタンス上でバッファされた後、非同期に EFS に書き込まれます。sync オプションでマウントされたファイルシステムにアクセスしたり、キャッシュをバイパスするオプション (例: O_DIRECT) を使ってファイルを開くと、代わりに EFS に対する同期リクエストが発行されます。
  • NFS クライアント構成 – 一部の NFS クライアントでは、読み込み/書き込みバッファに対して今日の標準よりもはるかに小さい値がデフォルトで使用されています。1 MiB への引き上げを検討してください (これは mount コマンドに対するオプションです)。EFS では NFS 4.0 または 4.1 クライアントを使用でき、4.1 の方が高いパフォーマンスを提供します。
  • EC2 インスタンス数 – 大量の I/O を処理するアプリケーションでは、大量のメモリや処理能力が必要となることがあります。十分なメモリと処理能力を用意し、適切なインスタンスサイズとタイプを選択してください。非同期読み込み/書き込みを実行する場合、カーネルでのキャッシュに追加のメモリが使用されます。また、EFS ファイルシステムのパフォーマンス特性は、EBS 最適化インスタンスの使用に左右されない点に注意してください。

ファイルシステムのベンチマークは技術と科学の融合です。成熟した信頼できるツールを使用し、複数回これらのツールを実行して、上記の検討事項に照らしながら結果を確認するようにしてください。期待されるパフォーマンスに関する詳しいデータは、Amazon Elastic File System ページでご確認いただけます。

ご利用について
EFS は、US East (Northern Virginia)、US West (Oregon)、Europe (Ireland) リージョンで、今日から使用を開始できます。料金は、保存データの量に応じて、1 日数回にわたるサンプルに基づき 1 か月あたりギガバイト単位で請求されます。通常通り日割り計算となり、US East (Northern Virginia) リージョンでの 1 か月の料金は、1 GB あたり 0.30 USD となります。最低料金やセットアップ料金はありません (詳しくは、EFS 料金表ページをご覧ください)。利用無料枠対象のお客様については、1 か月あたり最大 5 GB までの EFS ストレージを無料でご利用いただけます。

Jeff;

※6月末現在Amazon Elastic File Systemは東京リージョンで未提供です。対応リージョンは順次拡大の予定です。

 

 

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

AWS CodePipeline で、アクション失敗後のリトライが出来るようになりました。以前は、手動でパイプライン全体をリスタートするか、失敗したアクションをリトライするために、パイプラインの Source Stage へ新たな変更をコミットする必要がありました。

CodePipeline 内でアクションがうまく完了しなかった場合、そのアクションは失敗し、パイプラインが停止し、パイプラインを通じた更新を止めてしまいます。本日から、パイプライン全体をリスタートする必要なく、失敗したアクションをリトライできます。

本機能はマネジメントコンソール、 AWS CLI, AWS SDK, API を使用して、利用可能です。リトライ機能の詳細は こちらをご覧下さい。

CodePipelineに関する詳細:

翻訳は江川が担当しました。原文はこちら