Author: AWS Japan

リレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと2つの手法が上げられます。一般的にスケールアップの方が簡単に行えます(単純にスペックのいいマシンを購入するなど)。一方スケールアウトは、それぞれ独立したホストで稼働している複数のサーバへ、データベースをシャーディングする必要があり作業が煩雑になります。 難しさにも関わらずスケールアウトとが最近のトレンドとなってきています。コモディティハードウェアとシステムリソースへの要求の増加に伴いワークロードを効率的にシャーディングする必要が出てきました。シャーディングされたシステムの1つの欠点として管理コストがあげられます。もし4つのシャードを持っているとすると、4つのデータベースを管理する必要があります。しかし、たとえそうだとしてもスケールアウトはスケールアップよりコスト効率がいい場面が多かったのです。特にAmazon RDSの様なマネージドデータベースの登場によりリレーショナルデータベースの管理を軽減することが出来るようになったのがその1つの要因です。 しかし、なぜ過去形なのでしょうか? Amazon Auroraの登場によりスケールアップという選択肢が戻ってきたのです。Amazon Auroraは非常にスケールし、MySQL互換のマネージドデータベースサービスです。Auroraは2 vCPU/4 GiBメモリというスペックのインスタンスから、32 vCPU/244 GiBメモリ搭載のインスタンスまでを提供しています。Amazon Auroraは需要に応じてストレージが10 GBから64 TBまで自動的に増加します。また、将来のリードキャパシティの増加に備えて15インスタンスまで低遅延のリードレプリカを3つのアベイラビリティーゾーンに配置することが可能です。この構成の優れている点は、ストレージがリードレプリカ間でシャーディングされている点です。 シャーディングされたシステムを1つのAuroraインスタンスに集約、もしくは少数のシャードに集約しAuroraで稼働させることで多くのコストを節約する事が可能です。これがこのブログポストでお話したいことの全てです。 シャーディングされたシステムをAuroraに集約するために – まずはじめに – 多くのシャーディングされたシステムは標準的な方法で行うことが可能です。データはカスタマーIDなどの特定のキーを元に分割されており、何かしらマッピングを行う機能を用いてシャードに分割されています。この方法には様々な種類があり、1例として参照用のデータを別のシステムか1つのシャードに格納したり、全てのシャードに参照用のデータを配置するなどがあります。どのようにデータを分割しても、シャーディングの複雑さは通常、アプリケーションレイヤーにあり、シャードの統合は比較的容易に行えます。 多分皆さんは今、”利点はわかった。ではどうやってAuroraにデータを移行するのか”という疑問をお持ちかと思います。今回の例では、MySQLを利用して4つのシャードを持つシステムを利用していると仮定したいと思います。また、各シャードは他のシャードが持っているデータを持っていないものとします。また1つのシャードが参照用のデータを持っている前提とします。現在の構成は以下の図の様な構成になっていると思います。mapは各シャードへのアプリケーショントラフィックを表しています。 MySQLを運用しているため、Aurora documentationに記載されている方法を利用を利用可能です。簡単に移行を行うために、まずはじめに参照データのみが格納されているインスタンス1を移行します。しかし、どのシャードを最初に移行するかはそれほど重要ではありません。 移行が完了すると、マッピング機能はインスタンス1ではなくAuroraインスタンスを指します。システムは次の図のようになります。 残りのデータを移行する この時点で、Auroraが特定のワークロードをどれくらいうまく処理しているか評価し、必要な調整を行う必要があります。設定に問題がなくなれば、他のデータを移行する準備は完了です。では、シャード2をAuroraインスタンスに移行しましょう。しかし、どうやって？   AWS Database Migration Service (AWS DMS)を是非ご活用下さい！AWS DMSはこのようなマイグレーションにも対応するように作られました。シャード2からAuroraインスタンスへデータをコピーするためにDMSをご利用になれます。更に、シャード2にとランアクションを実行しながらこれらの作業が可能です。DMSは初期データのロードが完了すると、それらのトランザクションデータをシャード2から収集しAuroraインスタンスに適用します。DMSは継続的にシャード2からAuroraインスタンスへデータを移行し、シャード2の代わりにAuroraインスタンスの利用を開始させるまで同期させます。シャード2からAuroraインスタンスへ切り替える準備が出来たら、シャード2へのトランザクションを停止し、DMSが最後のトランザクションをAuroraインスタンスへ適用するまで待ち、mapの設定を、シャード2に向いていたトラフィックを直接Auroraインスタンスへ向くように変更します。設定が完了すると、システムは以下のような状態になります。 この時点から、Database Migration Serviceを残り2つのシャードをAuroraインスタンスへ移行するために利用出来ます。最終的にシステムは以下の様になります。   複雑なシャードの扱い方 これでシャーディングされたシステムが1つのAuroraインスタンスへマイグレーションが完了し、コストを削減することが出来ました！しかし、MySQLを利用し、クリーンなシャードを利用しているとう仮定で話をすすめてきました。もしこれらの仮定にそぐわない場合はどうでしょうか？ それでは、シャードがクリーンな状態でない場合を見ていきましょう。例えば、システムが最初に2つのシャードで構成されていたとします。ある時点で、その2つのシャードを4つのシャードに分割したとします。 リシャードィングプロセスの一環として、シャード1と2のコピーを作成してシャード3と4を作成し、マッピング機能を更新しました。 結果は次のようになります。 この図は状況が複雑であるように見えます。 理想的には、このようなリシャードィングの際に、シャードに関係のないデータ、つまりグレーアウトされたデータをパージします。 しかし、必ずしも必要というわけではないし、時には難しいこともあるので、データをそのままにしておく事があります。 この方法では使用されていない冗長なデータを保持する”汚れた”シャードが発生します。 これらのシャードを統合しようとすると、アクティブなデータの行が、削除すべき重複した行と衝突する問題が発生します。 何をすべきか？ シャードの統合を行う前に、利用していない行を削除することができます。 しかし、特にマッピング関数がID値のハッシュ（一般的な方法の1つ）で構成されている場合、利用していない行を特定するのは難しいかもしれません。 諦めないで下さい！ 別のオプションがあるかもしれません。 各シャード内のデータが1つのデータベースに含まれている場合は、DMSを使用して、システムの各シャードをAuroraインスタンス内の単一のMySQLデータベースに統合できます。 次に、既存のマッピング・スキームを使用して、Auroraインスタンス内の適切なデータベースにトランザクションを転送できます。 […]

2 月を終わるにあたって、Tina Barr が再びすばらしいスタートアップ企業をいくつかご紹介します。 -Ana 今月は、5 社の革新的でホットなスタートアップ企業をご紹介します。 GumGum – イメージ内広告という分野を作成、一般化。 Jiobit – 保護者が子供を追跡するためのスマートタグ。 Parsec – PC ゲーマー用のハードウェアと場所の柔軟性を向上。 Peloton – 家庭でのインドアサイクリングとフィットネス教室を変革。 Tendril – 自宅所有者のエネルギー消費を減らす。 1 月のスタートアップをすべてお読みになっていない場合は、ぜひこちらからご確認ください。 GumGum (カリフォルニア州サンタモニカ) GumGum はイメージ内広告という分野を開発し、一般化したことでよく知られています。Ophir Tanz 氏によって 2008 年に設立された同社は、ソーシャルメディア、論説、さまざまな業界のブロードキャストを通じて毎日作成される膨大なコンテンツ内に留まっている価値を解放するという目標を掲げています。GumGum は 2,000 以上の大手出版社でキャンペーンを行っており、4 億人以上のユーザーがこれを見ています。イメージ内広告は GumGum によって開発され、顧客の注目が既に集まっている場所に、非常に目立つ広告を配信するプラットフォームを企業に提供してきました。GumGum は画像認識技術を使用して、関連するイメージの状況に応じたオーバーレイ、あらゆる画面サイズに適応するバナー、または周囲のコンテンツにシームレスに融合するフィード内プレースメントとして、対象を絞り込んだプレイスメントを配信しています。GumGum は、Visual Intelligence を使って、ブランドに関連するあらゆるイメージや動画についてソーシャルメディアやブロードキャスト TV を検索し、視聴者についてと、視聴者がソーシャルメディアでそのブランドにどのようにかかわっているかをより良く理解できるようにしています。GumGum はイメージ処理と広告配信オペレーションに AWS を利用しています。現在、AWS のインフラストラクチャを使って、世界中で 1 分あたり 1300 万件のリクエストを処理し、毎日 30 TB […]

AWS のお客様は Amazon DynamoDB を十分に活用しています。お客様は、その速度と柔軟性を気に入り、一貫性がある数ミリ秒台のレイテンシーを活かした広告技術 (リファレンスアーキテクチャ)、ゲーム(リファレンスアーキテクチャ)、IoT (リファレンスアーキテクチャ)、およびその他のアプリケーションを構築しています。また、DynamoDB はマネージ型のサーバーレスデータベースとして、数テラバイトというサイズのテーブルに対する 1 秒あたり数百万件ものリクエストを処理するようにスケールできる点も好評です。多くの DynamoDB ユーザーは、有効期限があるデータや、時間とともにアクセス頻度が低くなるデータを保存している場合があります。最近のログイン、トライアルのサブスクリプション、またはアプリケーションのメトリクスを追跡する場合もあります。保存期間が規制または契約で制限されるデータを保存している場合もあります。このような場合、これまでは独自の時間ベースのデータ管理を導入していました。大規模なケースでは、DynamoDB 項目のスキャン、データ属性のチェック、不要になった項目の削除リクエストの発行などを行うためだけに、数個の Amazon Elastic Compute Cloud (EC2) インスタンスを実行することもありました。これに伴って、アプリケーションのコストと複雑さが増大しました。 新しい Time to Live (TTL) による管理 この一般的で重要なユースケースを効率化するため、当社は本日から、新しい Time to Live (TTL) 機能の提供を開始します。この機能をテーブルごとに有効にし、項目の有効期限を含む項目属性を指定できます。項目属性を指定して TTL 管理を有効にすると (1 回の API コールで両方のオペレーションを実行できます)、DynamoDB が、有効期限が切れた項目を見つけて削除します。この処理は自動的にバックグラウンドで実行され、テーブルに対する読み取りまたは書き込みトラフィックに影響を与えることはありません。DynamoDB ストリーム(詳細については、「Sneak Preview – DynamoDB Streams」を参照) を使用して、実際の削除を処理またはアーカイブできます。削除は、ストリームの他の更新レコードのように、ローリング期間の 24 時間ベースで使用できます。有効期限が切れた項目については、AWS Lambda および DynamoDB トリガーを使用してコールドストレージへの移動、ログへの記録、または他のテーブルの更新を行うことができます。テーブルに対して TTL を有効にし、必要な属性を指定する方法を次に示します。 属性は DynamoDB の数値データ型とする必要があり、UNIX […]

複数の AWS アカウントを管理しているお客様が少なくありません。いくつかの理由が考えられます。AWS を徐々に導入して全体に広げている組織では、個別のチームや部門が一元管理されることなくクラウドコンピューティングに移行している場合があります。合併や買収を通じて成長している組織では、既存のアカウントを引き継ぐ場合があります。厳格なコンプライアンスのガイドラインに従うため、またはアプリケーション間に強い隔離障壁を設けるための通常の対策として複数のアカウントを作成する場合もあります。さらに開発、テスト、実稼働の目的別に異なるアカウントを使用する場合もあります。アカウント数が増大すると、全体をスケーラブルに管理する方法が必要になります。お客様は、チーム、部門、アプリケーションごとのアカウントを個別に扱わずに、アクセスコントロールポリシーを定義して全体、一部、または個別のアカウントに簡単に適用する方法を求めています。このようなお客様は、さらに請求やコスト管理にも関心が高い場合が多く、ボリュームディスカウントやリザーブドインスタンスなどの AWS の料金面でのメリットを、より広範囲にアカウントに反映できることを希望しています。 AWS Organizations がプレビューから一般公開へ このユースケースの重要性が増していることから、本日より、AWS Organizations のプレビューを終了して一般提供を開始します。AWS Organizations では複数の AWS アカウントを一元管理できます。組織単位 (OU) の階層構造を作成して各アカウントを OU に割り当て、さらにポリシーを定義して階層構造の全体、特定の OU、または特定のアカウントに適用できます。また、既存の AWS アカウントを招待して組織に追加できます。新規アカウントを作成することもできます。以上のすべての機能は、AWS Management Console、AWS Command Line Interface (CLI)、および AWS Organizations API から利用できます。AWS Organizations の理解に役立つ重要な用語と概念をいくつか紹介します (ユーザーが組織の AWS アカウント全体に対して全権を持ち、マスターアカウントを担当する管理者であることを前提とします)。 組織は、管理対象の AWS アカウントの統合セットです。新しい組織を作成して、サービスコントロールポリシーなどの高度なアカウントレベルのコントロールを実装できます。組織の管理者は、アカウント別に許可および拒否する AWS API 関数やリソースのリストを管理できます。たとえば、先端 R&D チームには広範な AWS のサービスへのアクセス権を与え、メインストリームの開発およびテストアカウントにはアクセス権を一部制限できます。または、実稼働環境では、HIPAA の準拠に該当する AWS のサービスに限ってアクセスを許可できます。AWS の既存のお客様は、一括請求 (コンソリデーティッドビリング) と呼ばれる AWS […]

お客様からのご要望にお応えして、この「マイクロ」版の週刊 AWS を作成しています。当社からのすべてのお知らせ、当社のすべてのブログのコンテンツ、およびコミュニティで作成された AWS コンテンツをできるだけ多く含めました。今後、ツールや自動化の準備が整い次第、他のセクションもご紹介していきたいと思っています。 月曜日 2 月 20 日 Amazon Athena が AVRO データのクエリをサポートし、米国東部 (オハイオ) リージョンで利用可能になり、Looker と統合されることを発表しました。 AWS Marketplace 出品セルフサービスでソフトウェアベンダーによる既存製品の編集が可能になることを発表しました。 Amazon CloudWatch がダッシュボードでアラームをサポートするようになったことを発表しました。 AWS Database Blog が適切な DynamoDB パーティションキーの選択に関するアドバイスを公開しました。 N2WS がクラウド開発者に対して Amazon Lightsail を使用しているか質問するブログを公開しました。 火曜日 2 月 21 日 AWS Big Data Blog が Amazon QuickSight での SPICE データセットの更新予定に関するブログを公開しました。 AWS Database Blog が Amazon […]

 Lumberyard Beta 1.8のリリースを発表します。ここからダウンロードすることができます。このリリースには234以上の新機能、修正、機能が含まれており、1人のエンジニアでわずか30分で一般的なクラウド接続機能を構築するための新しいフレームワークのCloud Gems Frameworkが導入されています。 AWSのように、SupercellとZyngaのようなモバイルとソーシャルの初期のパイオニアから、Cloud ImperiumやLeslie BenziesのEverywhereのような銀河系の野望を持つPCやコンソール開発者まで、業界で最も優れたゲームスタジオの多くと協力できて幸運です。開発者は、イノベーションと成長のためにクラウドを活用し、以前は不可能だった規模でプレーヤー同士を結びつけ、新しい形の競争とゲームプレイを可能にし、ゲームについてのプレーヤーが好き、好きではない等よりディープにリアルタイムに情報を得ることができるようになりました。 お客様から、クラウドの膨大なコンピュートとストレージが今日の成功したゲームにとって重要であると同時に、クラウドは次世代ゲームの創造性とスケールにとってさらに重要なものになると教わりました。グローバルオーディエンスを結びつけるための開発者の需要、マスコンピューティングによる創造性の推進、より多くの社会的マルチプレイヤー機能の構築は”AWSと深く統合され”Lumberyardの基盤となりました。 我々は2つの方法で”深く統合”されたものを定義します。 1つは、マルチプレイヤー、ソーシャル機能、ダイナミックでライブで行えるコンテンツアップデートなど、共通の接続要素をゲームにできるだけ簡単に作成することです。熟練したバックエンドエンジニアを雇わず、未分化のインフラストラクチャを構築するために何ヶ月も何年も費やさずに、偉大なゲームプレヤーにフォーカスすることを望みます。次に、大規模なオンデマンドやグローバルなコンピュートとストレージによって可能になる、素晴らしい新しいタイプのゲームプレイとリアルタイムインタラクションを作成することをお手伝いします。ここでは、手続き型のゲームプレイ、複雑な人工知能、巨大かつ信憑性の高いゲームを考えているゲームチームからインスピレーションを得ています。 Lumberyard Beta 1.8の新しいCloud Gems Frameworkを使用すると、動的コンテンツ、リーダーボード、ライブメッセージなどのコネクティッドなゲーム要素を簡単に作成して起動できます。 Cloud Gems Frameworkを使用すると、1人のエンジニアが30分以内にゲームにコネクティッドな機能を追加することができ、残りのチームエンジニアがイノベーションとプレイヤー体験について考えるようになります。 Cloud Gems Frameworkは、チームの誰もがクラウドの機能を視覚的に管理できるWebアプリケーション（メッセージのスケジュール設定、動的コンテンツのリリース、または不正なリーダーボードスコアの削除など）であるCloud Gem Portalと開発者がバックエンドやクライアントの機能を含め、その機能をプロジェクトに組み込むために必要なすべてを含む個別機能と資産のモジュールパッケージであるCloud Gemsで構成されています。Cloud Gemは、本番環境ですぐに使用でき、様々な方法で動作をカスタマイズしたい場合に備えて完全なソースコードが付属しています。 Lumberyard Beta 1.8には、3つのサンプルのCloud Gemsが含まれており、すぐに始めることができます。 Dynamic Content Cloud Gem 今日の成功したゲームの多くはサービス中で常に”常時オン”になっています。チームはできるだけ開発チームに苦労することなく、頻繁にコンテンツを追加したり変更したりすることで、プレイヤーの関与を深めたいと考えています。ダイナミックコンテンツバックエンドを使用すると、プレイヤーが更新された実行ファイルをダウンロードしてインストールする必要なく、チームはプレーヤーのフィードバックに迅速に応答したり、特殊文字やA / Bテストゲームプレイ機能を提供したり、新しいキャラクタやレベルをゲームに追加してゲームの寿命をのばすことができます。 ダイナミックコンテンツシステムを自分で構築するには、コンテンツをホストするサーバーを立ち上げ、利用可能な動的コンテンツを指定するスキームを作成し、コンテンツのバージョン管理を行い、サーバーにコンテンツをアップロードするツールを作成し、サーバーに照会してコンテンツがいつ変更されたかを確認するエンジンを書き、堅牢なダウンロードおよび検証システムを構築し、最終的にはゲームを動かすインスタンスにホットロードするコードを記述すします。この作業には2〜3人のエンジニアが数ヶ月かかることがあります。このシステムが失敗すると、プレーヤーはあなたのチームが作成した内容を決して見ることができません。 Dynamic Content Cloud Gemを使用すると、わずか7ステップでコンテンツをパッケージ化、アップロード、および配信することができます。 Lumberyard Project ConfiguratorでDynamic Content Gem を有効にする Cloud Canvas Resource Managerから[Upload Resources]をクリックします。 エディタのAWSメニューからDynamic Content […]

うれしいお知らせです。AWS Elastic Beanstalk でカスタムプラットフォームを作成できるようになりました。この最新リリースの AWS Elastic Beanstalk により、開発者やシステム管理者は、AWS Elastic Beanstalk のカスタムプラットフォームイメージを独自に作成して管理し、インスタンス設定を完全にコントロールできます。ご存じのように、AWS Elastic Beanstalk は、一般的なウェブプラットフォームでウェブアプリケーションやサービスをデプロイ、スケーリングするためのサービスです。このサービスでは、ユーザーがコードをアップロードするだけで、デプロイメント、容量のプロビジョニング、負荷分散、Auto Scaling が自動的に処理されます。 これまでの AWS Elastic Beanstalk で提供していたのは、事前設定済みのプラットフォームのセットです。さまざまなプログラミング言語、Docker コンテナ、上述した用途別のウェブコンテナの設定が複数用意されていました。Elastic Beanstalk では、選択された設定に従って、1 つ以上の Amazon EC2 インスタンスで対象のアプリケーションを実行するためのソフトウェアスタックやリソースをプロビジョニングしていました。この最新リリースでは、独自のカスタマイズした Amazon Machine Image (AMI) からプラットフォームを作成できます。カスタムイメージは、サポートされているオペレーティングシステム (Ubuntu、RHEL、Amazon Linux) のいずれかで構築できます。これらの特化された Elastic Beanstalk プラットフォームの作成作業は、マシンイメージ作成ツールの Packer で簡素化できます。Packer は、すべての主要オペレーティングシステムで実行するオープンソースツールであり、1 つの設定から複数のプラットフォームのマシンイメージやコンテナイメージを作成できます。カスタムプラットフォームでは、Elastic Beanstalk 環境全体にわたり、標準化とベストプラクティスを適用して管理できます。たとえば、Ubuntu や Red Hat Enterprise で独自のプラットフォームを作成し、Elastic Beanstalk で現在サポートされていない言語やフレームワーク (Rust、Sinatra など) を使用してインスタンスをカスタマイズできます。 […]

Amazon QuickSightにSPICEデータのスケジュールリフレッシュ機能が追加されました。以下はAWS Bigdata Blogに掲載されたブログの翻訳です。 Jose KunnackalはAmazon QuickSightのシニアプロダクトマネージャ 2016年11月に私達はAmazon QuickSightをローンチしました。これはクラウドのパワーで稼働し、お客様のデータをクイックかつ簡単に分析するビジネスアナリティクスのサービスです。QuickSightはSPICE (Super-fast, Parallel, In-Memory Calculation Engine)というフルマネージドのデータストアを持っており、これにAWSやオンプレミス、クラウドサービスのデータを格納することで超高速なビジュアライゼーションを可能にします。SPICEに格納したデータはQuickSight上にあるボタンをクリックするだけでいつでもリフレッシュ（新しいデータの取り込み）を行うことが可能です。 本日、リフレッシュのスケジュール実行機能をローンチいたします！ SPICEデータセットをスケジュールリフレッシュする SPICEデータセットを選択し、スケジュールリフレッシュを指定します。その後、タイムゾーン、リフレッシュ頻度、およびスケジュールの開始日時を指定します。 スケジュールを適切に設定することで、SPIPCEのデータセットや分析、ダッシュボードを元のデータソースに同期させることが可能になります。 スケジュールリフレッシュはサポートされるすべてのデータソース、つまりAWS、クラウドサービス、およびオンプレミスにあるデータに対して有効であり、全サポートリージョンのすでに作成済のデータセットについても利用可能です。手動でのリフレッシュと同様に、データセットのリフレッシュ状況のサマリを確認することが可能です。 データのスケジュールリフレッシュによって高いパフォーマンスを発揮するインタラクティブなダッシュボードをQuickSightとSPICEでシンプルに実現可能です。データリフレッシュのために所定の時間にQuickSightにログインする必要もありませんし（もしくはうっかり忘れることもなくなります）、QuickSightを活用して高速でインタラクティブなビジュアライゼーションを多くのユーザに提供することにフォーカスできます。 QuickSightのパワーをぜひ今日から体験してみてください – 無料枠がありますのでぜひサインアップを！もしご質問などがありましたら、コメントを残してください。 （訳注：QuickSightには全機能を60日間試せるFree Trialがあります。また、機能は制限されますが無料でずっと利用できるFree Tierも用意されています。詳しくはこちらをご確認ください。） 原文：https://aws.amazon.com/jp/blogs/big-data/scheduled-refresh-for-spice-data-sets-on-amazon-quicksight/ 翻訳：下佐粉 昭 (@simosako)  

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー3月の配信についてご案内させて頂きます。今月は2月にリリースされたばかりの「Amazon Chime」をはじめとして、初登場となるサービスが多数あります！ 3月の開催予定 サービスカット 3/1(水) 18:00-19:00 Amazon Athena 3/8(水) 18:00-19:00 Amazon Chime 3/15(水) 18:00-19:00 Auto Scaling 3/22(水) 18:00-19:00 Developer Tools (CodeX シリーズ) 3/29(水) 18:00-19:00 Amazon AI ソリューションカット 3/14(火) 12:00-13:00 Well-Architected Framework 3/28(火) 12:00-13:00 動画配信 on AWS お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。

お客様からビジネスのダイナミックさと、それを実現するためのアプリケーションがブロックストレージに求めるものについてご意見をうかがうことは、いつも興味深いものです。ビジネス状況の変化に伴ってブロックストレージへの要求も変化し、容量を追加したり、性能特性の異なるボリュームが必要になったりすることもあるはずです。今日では、24時間運用され続けるシステムも珍しくはありません。結果として、ダウンタイムやシステム運用への影響なく変更作業を行えることがお客様にとって重要な要素となってきます。 我々は長年にわたり、お客様の様々なユースケースをカバーするために、EBSに新機能を追加し続けてきました。例えば、2016年にはスループット最適化HDD(st1)とコールドHDD(sc1)という2種類のボリュームタイプをリリースしました。これらのボリュームをシステム運用への影響なく、パフォーマンス特性の変更やコスト削減を行うことで、階層化ストレージのように利用したいと考えるお客様がいらっしゃいます。言い換えると、お客様はEBSがより柔軟になることを望んでいるのです！ エラスティックボリューム 本日、EBSの新機能としてエラスティックボリュームをリリースいたしました。これは現行世代のEC2インスタンスにアタッチされた、全ての現行世代のEBSボリュームで利用可能です。お客様はボリュームサイズの拡張、パフォーマンスの調整、ボリュームタイプの変更を利用中に行うことができます。変更処理はオンラインで行われますので、お客様のアプリケーションは引き続き利用可能でダウンタイムはありません。 この新機能はリソース計画やチューニング、空き容量の管理といった作業を劇的にシンプル化してくれます。あるいは作業自体が不必要になるかもしれません。従来のやり方はダウンタイムを伴うため、変更の完了までプランニングやシステム停止の調整を含めると数週間から数ヶ月にわたる時間が必要でした。しかしこれからは、利用しているストレージインフラストラクチャをシンプルなAPIコールで簡単に変更することが可能になります。 ワークロードの変化 – インフラ構築を急ぐ必要があり、汎用SSDボリュームを採用することにしました。システムをリリースし、運用を行っていくにつれて、スループット最適化HDDボリュームが最適であることに気づいたとしましょう。エラスティックボリュームの機能により、単純にボリュームタイプを変更するだけで対応が完了します。 突発的な需要への対応 – プロビジョンドIOPSボリューム上に構築したリレーショナルデータベースで、1ヶ月のほとんどの期間にわたり問題なく処理を行えるシステムがあります。ただし月末処理の関係で各月終わりの3日間は10倍のトラフィックを処理する必要があったとします。この場合は、エラスティックボリュームを利用して月末の3日間だけIOPSを高く設定し、処理が終わったら元に戻すという運用が可能です。 ストレージの増加 – 100GBのボリュームで運用してきたシステムで、ディスク使用率が90%を超過したというアラームが発報しました。あらかじめ設定を行っておけば、ボリュームとファイルシステムの拡大を自動的にダウンタイム無しで行うこともできます。 エラスティックボリュームの利用 お客様はこれら全ての操作をAWSマネジメントコンソールやAPIコール、AWSコマンドラインインタフェース(CLI)で実行できます。これに加えて、AWS CloudFormationのスタック更新機能を利用することも可能で、対象のボリュームに必要な変更を行ってくれます。コンソールを利用する場合は、対象のボリュームを選択してアクションメニューから「Modify Volume」を選択するだけです: ポップアップするウィンドウの中で、ボリュームタイプやサイズ、IOPS値(プロビジョンドIOPSボリュームの場合)を変更してください。これは75GBの汎用SSDボリュームを、20,000IOPSで400GBのプロビジョンドIOPSボリュームに変更する例です: 変更ボタンをクリックしたら、確認ウィンドウが表示されるので問題が無ければ「YES」をクリックします: ボリュームの「状態」に変更処理の進捗状況(modifying、optimizing、completed)が表示されます: 次のステップは追加されたストレージ領域を利用できるようにするために、ファイルシステムを拡張することです。作業の詳細についてはLinuxでEBSボリュームのストレージ領域を拡張するかWindowsでEBSボリュームのストレージ領域を拡張するを参照してください。ボリュームの状態が最適化中に変わったら(通常数秒で変わります)、ファイルシステムの拡張作業を行うことができます。新しいボリュームの容量やタイプはすぐに利用可能になりますが、最適化の処理は最大で24時間を要する場合があります。コストについて補足すると、ボリュームの状態がoptimizingになったタイミングで新構成を基準に計算されることになります(変更自体のコストはかかりません)。 エラスティックボリュームの自動オペレーション 手動オペレーションでの変更も充分に魅力的ですが、自動化を行うたくさんのチャンスがあります。いくつかのアイデアをお見せしてみましょう: 正しいサイジング – IOPS上限か、それに近いレベルに到達しているかをCloudWatchで監視しアラームを上げるよう設定します。アラームが上がったらIOPS値の増加や、ボリュームタイプの変更を行うための承認プロセスを開始し、変更作業の準備を進めます。同様にCloudWatchのカスタムメトリクスを利用して空き容量をモニタリングして、拡張のための承認プロセスを開始することもできます。 コストの削減 – CloudWatchメトリクスや予め設定したスケジュールに従ってIOPSの削減やボリュームタイプの変更を行います。（背景：先週、大学のセキュリティ管理者と会話する機会がありました。彼は学内の全てのサーバから1日に10GBのログを収集し、60日間に渡って保持するという仕事をしています。ほとんどのファイルは参照されることはなく、参照が必要になったときでもアクセス速度はそれほど求められません。この場合、1日分のログを書き込むための汎用SSDボリュームを作成し高速な書き込みを実施し、完了したらスループット最適化HDDに変更することでコストを最適化することができます。） 先にお伝えしたように、新たに追加された領域を利用できるようにするためにはファイルシステムをリサイズする必要があります。この手順をお見せするために、私の同僚がCloudWatch Events、AWS Lambda、EC2 Systems Managerを利用したPythonとPowerShellのサンプルスクリプトを提供してくれました。このルールはEBSから送信される情報に基づきmodifyVolumeというイベントにマッチし、logEventsというLambdaファンクションを起動します: このファンクションは対象となるボリュームを特定し、これがEC2 Systems Managerで管理されるインスタンスにアタッチされていることを確認したうえでメンテナンス用のタグ情報を付与します: def lambda_handler(event, context): volume =(event[‘resources’][0].split(‘/’)[1]) attach=ec2.describe_volumes(VolumeIds=[volume])[‘Volumes’][0][‘Attachments’] if len(attach)>0: instance = attach[0][‘InstanceId’] filter={‘key’: ‘InstanceIds’, ‘valueSet’: [instance]} info = […]