Amazon Web Services ブログ

Amazon RDS for SQL Server – Amazon S3 でネイティブバックアップと復元をサポート

このブログを定期的にご覧になっている読者の方々であれば、私が Amazon Relational Database Service (RDS) のファンなのをご存知でしょう。これは設定、実行、リレーショナルデータベースのスケーリングなど、より定期的な操作に対応できるマネージド型データベースサービスです。2012 年の開始以来、SQL Server サポートSSL サポートメジャーバージョンのアップグレード透過的なデータの暗号化拡張モニタリングMulti-AZ などの機能追加に努めてきました。そして今回、SQL Server のネイティブバックアップと復元のサポートが追加されるようになりました。SQL Server のネイティブバックアップには、テーブル、インデックス、ストアドプロシージャ、トリガーなど、すべてのデータベースオブジェクトが含まれています。主に、こうしたバックアップはオンプレミスで実行もしくはクラウドで実行している SQL Server インスタンス間でデータベースを移行する場合に使用されています。またデータの取り込み、災害対策などにも使用することができます。ネイティブバックアップは、オンプレミスの SQL Server インスタンスからのデータインポートやスキーマのプロセスを簡略化することもできるので、 SQL Server DBA が機能しやすくなります。

ネイティブバックアップと復元のサポート
RDS インスタンスからネイティブ SQL データベースのバックアップを取り、Amazon S3 バケットに保管できるようになりました。バックアップは SQL Server のオンプレミスコピーまたは他の RDS を使用する SQL Server インスタンスに復元することも可能です。さらにオンプレミスデータベースのバックアップを S3 にコピーし、RDS SQL Server インスタンスに復元することもできます。Amazon S3 で行う SQL Server のネイティブバックアップと復元は、すべての SQL Server エディションで AWS Key Management Service (KMS) を使用するバックアップの暗号化をサポートします。S3 を通じて AWS でバックアップの保管や移行を行うと、別の災害対策オプションが提供されます。SQL_SERVER_BACKUP_RESTORE オプションをオプショングループに追加し、そのグループと RDS SQL Server インスタンスをリンクすれば、この機能をオンにすることができます。このオプションは S3 バケットの情報でも設定しておく必要があります。また、バックアップを暗号化するために KMS キーを追加することもできます。希望のオプショングループを検索します。

次に SQL_SERVER_BACKUP_RESTORE オプションを追加し、IAM ロールを指定 (または作成) して RDS が S3 にアクセスできるようにします。バケットにポイントし (希望するのであれば) 暗号化を特定し設定します。


設定が完了したらSQL Server Management Studio を使用してデータベースインスタンスに接続し、必要に応じて次のストアドプロシージャ (msdb データベース内で利用可能) を呼び出します。

  • rds_backup_database – 1 つのデータベースを S3 バケットにバックアップします。
  • rds_restore_database – S3 から 1 つのデータベースを復元します。
  • rds_task_status – バックアップの実行を追跡しタスクを復元します。
  • rds_cancel_task – 実行中のバックアップをキャンセルするかタスクを復元します。

詳細はSQL Server データのインポートとエクスポートをご覧ください。

ご利用可能
SQL Server のネイティブバックアップと復元サポートは US East (Northern Virginia)、US West (Oregon)、Europe (Ireland)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Asia Pacific (Singapore)、Asia Pacific (Mumbai)、South America (Brazil) リージョンでご利用いただけます。 本機能を Amazon RDS for SQL Server でご利用されるにあたり追加費用はありませんが、Amazon S3 ストレージの使用量は通常料金で請求されます。

Jeff

【イベント開催】Thanks for coming AWS GAMEDAY JAPAN!!!

AWS Gamedayはご存知でしょうか。毎年re:Inventで大々的に行われ、世界中から多くのエンジニアが参加するイベントになります。先週の土曜日(7/23)に、そのGamedayが日本に上陸しました!目黒のAWSオフィスを会場に、我こそAWS スペシャリストという強者が集い、Gamedayを楽しんで頂きました。本日はその内容をダイジェストでご紹介させて頂きます。

そもそもAWS Gamedayとは?

AWS上に構築されたシステムのトラブルシュートコンテストのようなものです。当日はチーム戦(2-3名/Team)となり、チーム毎に”ある”AWS環境が主催者から払い出されます。払いだされた環境をスケーラブルで可用性の高いシステムへパワーアップさせ、かつコストも最適化する、いわばDevOpsチャレンジのようなイベントになります。皆さんの環境には、常に運営者サイドよりランダムな負荷がかけられ、リクエストをさばいた分だけポイントが加算されます。参加者の皆さんの中で、最もポイントを獲得したチームがチャンピオンとなります。

当日のアジェンダ

Gameday: 13:00-18:00

Presentation/Award: 18:00-19:30

13:00-13:30 の30分間、運営者からGamedayの趣旨と楽しみ方についてご説明し、早速スタート!5時間の長丁場となります。イベントの概要は下記を御覧ください。

初回の今回は12チーム、40人の方に参加頂きました。当日の様子はこのような感じです。各チームの状況と順位がリアルタイムで確認できるようにダッシュボードは運営者から提供しています。各チーム登録が無事完了し、順調にスタートしていますね。

Pic-gd-01.JPG

Pic-gd-02.JPG

チーム戦ということもあり、しゃべりながら、スナック、ドリンクを飲みながら和気あいあいと5時間楽しんで頂きました。土曜日ということもあり、16:00にはアルコールも入り、とてもリラックスして参加頂いたと思います。

そして5時間にわたり運営者からのトラップを見事しのぎ、最も高得点を獲得した第1回めのチャンピオンは、Shoroumaruチームとなりました!Top 3チームには、どのようにして高得点を出したかについてご説明頂きました。そして今回はGameday日本上陸記念ということで、特別に優勝チーム皆さんに、5,000円分のAmazon ギフトカードをサプライズプレゼント!

Shoroumaruチームの皆さん、おめでとうございました!!!

Pic-gd-03.JPG

参加頂いた方には、参加賞としてAWS Gamedayステッカーをもれなくプレゼント!とても満足いただいたようなので、機会があれば2回目も是非検討させていただきたいと思います。参加された皆さん、長時間に渡りお付き合い頂き、ありがとうございました!

Pic-gd-04.JPG

Twitterは#AWSGameDayJapanのハッシュタグを検索してみてください。

また今年のre:Invent 2016も11/28-12/2@LasVegasで予定されています。Gamedayも予定されていますので、是非現地でご参加頂ければと思います。大分席も埋まって来ましたので、ご登録はお早めに!(日本語サイトはこちら) また、日本から参加されるみなさまにはツアーもご用意しています。ツアーの詳細とお申し込みはこちらです。(請求書払い可能)

See you soon!!

AWS Gameday Team: Unicorn Rentals (AWS SA Team 桑野、星野、酒徳)

AWS が Amazon の記録更新に貢献

今年で 2 年目となった Prime Day で Amazon は新記録を達成しました。この日、世界中からの注文数はブラックフライデー、サイバーマンデー、Prime Day 2015 の記録を遥かに上回るものとなりました。Slice Intelligence は、Prime Day 2016 の当日における米国全土の e コマース消費者のうち 74% を Amazon が占めていたと報告しています。この 1 日限りのグローバルショッピングイベントは Amazon Prime メンバーのみを対象としています。Prime 2015 に比べ、今年のトラフィックレベルは過去最高そして Amazon Mobile App からの注文数は昨年の 2 倍にも上昇しました。世界中の Prime メンバーが 1 日に購入したアイテムの例として、玩具は 2 万個以上、靴は 1 万足以上そしてテレビは 9 万台以上の売り上げが記録されています (統計の詳細は Amazon’s Prime Day is the Biggest Day Ever をご覧ください)。これほど大きなスケールのイベントを実施するには、急増するトラフィックにインフラストラクチャが対応できなければなりません。

 

AWS スタイルでスケーリング
Amazon の小売用ウェブサイトはウェブトラフィックの対応に複数の EC2 インスタンスを使用しています。
Prime Day に急増するカスタマートラフィックに対応するため、Amazon のリテールチームは多数の EC2 のサイズを増やし、2009 年の時点での AWS と Amazon.com を合わせたサイズに等しい能力を追加しました。リソースは世界中の複数の AWS リージョンから取得しました。7 月 11 の朝は涼しく、Amazon シアトル本社のビルの上にはいくつかの雲が浮かんでいました。午前 8 時が近付く頃、Amazon リテールチームは Prime Day 第 1 弾となる最初の 10 件のリリース準備を完了していました。太平洋の反対側は、ほぼ午前 0 時を刻む頃です。日本では Prime Day の開始を待ち侘びる Prime メンバー達がそれぞれのスマートフォン、タブレット、ラップトップに釘付けの状態で待っていました。日本のトラフィックが急増し始めると、CloudWatch メトリックスで Amazon CloudWatch のエンドポイントや ElastiCache ノードが光り、高速モバイルやウェブリクエストが増加していることを示しだしました。このトラフィックの波は地球を一周し、ヨーロッパから米国に到達するまでに 40 時間、そしてクリックストリームのログエントリーは 850 億件を記録しました。 今年の Prime Day の注文数は Prime Day 2015 に比べ世界中で 60% そして米国内だけで 50% も上昇しました。モバイルでは 100 万人を超える Prime メンバーが Amazon Mobile App を初めてダウンロードし、アプリを利用したことが分かっています。Prime Day に伴い 38 種類 (下記サービスを含む) の AWS サービスの使用率が大幅に増加したことに Amazon.com は気付きました。

Prime Day のスケールと、その他の AWS をご利用されているお客様が、これに類似する大規模で 1 日限りのイベントをホストする機会があるかもしれませんので、より詳しく複数の AWS サービスの視点から Prime Day についてご説明します。

  • AmazonMobile Analytics イベントは前週の同じ曜日と比較すると 1,661% 上昇しました。
  • Amazon が使用する CloudWatch メトリックスは Prime Day の当日、前週の同じ曜日と比較すると世界中で 400% 上昇しました。
  • DynamoDB は Prime Day の当日、前週の同じ曜日と比較すると世界中で 560 億件以上のリクエストに対応しました。

AWS で実行
AWS チームは他の企業への対応と同様に Amazon.com に対応しています。この 2 つの組織はビジネスパートナーであり、定義済みのサポートプランやチャネルを通じてコミュニケーションを取っています。比較的に形式的なこのスタイルを取り入れることで、AWS チームが AWS をご利用されているお客様全員に提供するサポートプランやコミュニケーションプロセスを改善しやすくしています。Amazon のウェブサイトや AWS でモバイルアプリを実行することは、Prime Day のように短期間でありながらスケールの大きなグローバルイベントを実施することを可能にし、低コストに抑えることを実現します。私が Amazon.com に入社した 2002 年の時点では (ウェブサイトが AWS に移行する以前のことです)、ホリデーショッピングのシーズン準備には実に様々な計画を練り、予算組みや効果なハードウェアの購入などを必要としていました。このハードウェアはトラフィックの増加に対応する上で役立っていましたが、別の意味ではトラフィックが平常に戻り次第 Amazon.com が未使用でほぼ利用されていないハードウェアを無駄に所有していることを意味していました。AWS は、お客様が Prime Day のようなスケールの大きいイベントを実施するために必要な処理能力を追加できるようにし、柔軟性を備えコスト効率が良い方法で、そうした機能を利用できるようにしています。AWS は、これほどのスケールのオンラインイベントを実施する上で必要とする作業に対応できるので、Amazon リテールチームはお客様にできる限り最高のユーザーエクスペリエンスを提供することに専念できるようになりました。

今回の教訓
Amazon リテールチームは Prime Day の終了に安堵感を感じながらも、今回の件で学んだ点を教えてくれました。

  • 準備 – 計画とテスト実施は必須である。過去の傾向をもとに、将来のトラフィックについて予測し計画を練ること。それに応じて必要なリソースを予測すること。GameDay エクササイズで問題発生時の対応を事前に準備する – インフラストラクチャやサイトのいくつかの部分で意図的に障害を起こし、複数の障害が発生した時の状況をシミュレーションすること (Amazon の GameDay エクササイズ詳細については Resilience Engineering – Learning to Embrace Failure をご覧ください)。
  • 自動化 – 手動による作業を減らし、すべて自動化すること。デマンドに自動的に応じることができるサービスのメリットを活用すること。例えば Route53 を使用して自動的に拡張したり、デマンドに応じて EC2 を自動拡張、また Elastic Load Balancing を使用して自動フェイルオーバーを可能にし複数のリージョンやアベイラビリティゾーンに渡りトラフィックのバランスを取るなど (AZ)。
  • モニタリングAmazon CloudWatch メトリックスを使用して柔軟に通知を送信すること。CloudWatch モニタリングは優れた顧客体験を提供できるように、使用法を常に把握できるようにデザインされている。
  • 自由な発想 – AWS を使用することで、チームに別のホリデーシーズンに必要なリソースを提供できたこと。自社のインフラストラクチャに対する自信がスケールの大きなイベントの実施に繋がる。

前述しましたが、これほどのスケールのイベントを計画し実施しない理由はどこにもないこと。スケールの大きな発想を、そしてサポートプランやサービスのメリットを活用すること。ソリューションアーキテクトやテクニカルアカウントマネージャーそして APN コンサルティングパートナーが必要に応じてご協力します。スケールの大きい 1 度限りのイベントを計画しているのであれば、ぜひお知らせください。イベント開始前そして終了後に必要なサポートをご提供いたします。

Jeff

PS – Prime Day で何を購入されましたか?

Amazon AuroraでMySQLバックアップからクラスタを作成可能になりました

AWSをご利用になり、クラウドへ移行するメリットを感じられているお客様から、アプリケーションやリレーショナルデータベースに保存されている、大量のデータを移行するより良い方法を良く質問されます。

本日、Amazon Auroraにて重要な新機能をリリースしました。既にオンプレミス環境やAmazon EC2インスタンス上でMySQLをお使いの場合、既存のデータベースのバックアップを取得し、スナップショットバックアップをAmazon S3にアップロード行い、そのスナップショットバックアップを利用して、Amazon Auroraクラスタを作成可能になりました。既存のAmazon AuroraのMySQLデータベースからレプリケーションを行える機能と合わせて利用することで、MySQLからAmazon Auroraへアプリケーションを停止させず簡単にマイグレーション可能です。

この新機能を利用することで大容量のデータ(2TB以上)をMySQLデータベースからAmazon Auroraへ移行元データベースへパフォーマンスインパクトを最小限にして効率的に移行を行うことが可能です。私達の行ったテストではmysqldump utilityを利用した場合と比較して20倍高速に処理が行えました。移行対象データベースにInnoDBとMyISAM形式のテーブルが双方が含まれていても移行は可能ですが、移行前にMyISAMからInnoDBへ変換を行っておくことをお勧めします。

移行方法について簡単にご説明します:

    1. 移行元データベースの準備 – 移行元データベースでバイナリログを有効化し。移行期間中バイナリログが残っているように設定を行って下さい。
    2. 移行元データベースのバックアップ – Percona Xtrabackupを利用して移行元データベースから”ホット”バックアップを作成します。このツールはデータベース、テーブルやトランザクションをロックしません。圧縮形式のバックアップを作成可能です。1つのバックアップファイルや複数の小さなバックアップファイルを作成頂けます。Amazon Auroraではどちらの形式でもご利用頂けます。
    3. S3へアップロード – S3へバックアップファイルをアップロードします。5TB未満のバックアップの場合は、AWS Management ConsoleAWS Command Line Interface (CLI) を利用してアップロードを行います。さらに大きなバックアップデータの場合は、AWS Import/Export Snowballを利用することをご検討下さい。
    4. IAM Role – Amazon Relational Database Service (RDS) がアップロードされたバックアップデータとバケットにアクセスするためにIAM roleを作成します。このIAM roleでは必ず、RDSがListBucketGetBucketLocation の操作をバケットに実行でき、GetObject の操作をバックアップデータに行える必要があります (サンプルポリシーはドキュメントで確認頂けます)。
    5. クラスタの作成 – 新しいAmazon Auroraクラスタをアップロードしたバックアップデータから作成します。RDSコンソール中のRestore Aurora DB Cluster from S3をクリックし、移行元データベースのバージョン番号を入力します。そして、S3バケットを選択し、IAM roleを選択後、Next Stepをクリックします。その後、クラスタ作成ページ(DB Details と Configure Advanced Settings)の残りの項目を入力します。rds_aurora_pick_src_backup

      Amazon Auroraはバックアップファイルをアルファベット順に処理します。

    6. MySQLスキーマの移行 – ユーザ、権限やMySQL INFORMATION_SCHEMAで行っていた設定を移行します。
    7. 関連するアイテムの移行 – trigger, functionやstored procedureを移行元データベースからAmazon Auroraクラスタに移行します。
    8. レプリケーションの設定 – 移行元データベースとAmazon Aurora間でレプリケーションを設定し、レプリケーションを追いつかせます。
    9. データベースの変更 – 全てのクライアントアプリケーションの接続先をAmazon Auroraクラスタに変更します。
    10. レプリケーションの停止 – Amazon Auroraクラスタへのレプリケーションを停止します。

本番環境でミッションクリティカルなデータベースの移行前には、移行の検証をお勧めします。

本日からご利用いただけます

この新機能は本日からAsia Pacific (Mumbai)リージョンを除く全てのリージョンでご利用いただけます。さらに詳細な情報はAmazon Aurora User Guide中のMigrating Data from an External MySQL Database to an Amazon Aurora DB Clusterをご覧ください。

Jeff; (翻訳は星野が担当しました。原文はこちら)

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