Amazon Web Services ブログ

AWSを利用頂いている多くのお客様にDynamoDBは使用されています。速度と柔軟性がその理由で、Ad Tech（ リファレンスアーキテクチャ ）、Gaming（ リファレンスアーキテクチャ ）、IoT（ リファレンスアーキテクチャ ）、そして一貫した一桁のミリ秒のレイテンシを実現しアプリケーションを構築されています。また、DynamoDBはフルマネージドのデータベースで、テラバイトサイズのテーブルに対して毎秒何百万というリクエストを処理することができます。 多くのDynamoDBユーザーは、利用する時間が限られている、または時間の経過とともにアクセス頻度が低くなるデータを格納しています。 直近のログイン、試用版のサブスクリプション、アプリケーションのメトリックなどへの利用がそうです。 他にも保管できる期間に関する規制または契約上の制限の対象となるデータを保管します。 これまで、これらを実現するには独自の時間ベースのデータ管理を実装していました。 大規模なシステムでは、DynamoDBアイテムのスキャン、期間を管理するための日付属性の確認、および不要になったアイテムの削除要求を行う為のAmazon Elastic Compute Cloud（EC2）インスタンスを構築するなどの必要があり、これによりアプリケーションのコストと複雑さが増加していました。 新しいTime to Live（TTL）管理 について この普及した重要なユースケースを合理化するため、新しくTTL（Time to Live）機能の提供を開始しました。 アイテムの有効期限を属性で指定する事により、テーブル単位でこの機能を有効にすることができます。 属性が指定され、TTL管理が有効になると（1回のAPI呼び出しで両方の操作が処理されます）、DynamoDBは期限切れのアイテムを見つけて削除します。 この処理は、自動的かつバックグラウンドで行われ、テーブルへの読み取りまたは書き込みトラフィックには影響しません。 DynamoDBストリームを使用することで（詳細は、「 DynamoDBアップデート – トリガ（Streams + Lambda）+クロスリージョンレプリケーションアプリケーション」を参照）。実際の削除を処理またはアーカイブすることができます。 ストリーム内の他の更新レコードと同様に、削除は24時間単位で行われます。 AWS LambdaおよびDynamoDB Triggersを使用して、期限切れのアイテムをコールドストレージに移動したり、ログに記録したり、他のテーブルを更新したりすることができます。 テーブルのTTLを有効にして、必要な属性を指定する方法は次のとおりです。 指定する属性はDynamoDBのNumber型かつ、 UNIX時間でTTLの指定を行います。 上のスクリーンショットからわかるように、DynamoDB Streamsを有効にすることもできます。また、TTLを有効にすると削除されるアイテムのプレビューを見ることもできます。 また、コードからUpdateTimeToLive関数を呼び出しテーブルにTTLの有効化設定することも、 AWSコマンドラインインターフェイス（CLI）からupdate-time-to-liveコマンドを使用しテーブルでTTLを有効化設定することもできます。 TTL の利用事例(TUNE様)  AWSのお客様であるTUNEは既に、この機能をHasOffers製品の一部として活用しています。 HasOffersは、マーケティングキャンペーンの効果を分析し、大量の広告エンゲージメントデータをプロセスに保存するのに役立ちます。 キャンペーンの顧客定義の時間枠が過ぎると、データは不要になり、削除することができます。 TTL機能をTUNEで使用できるようにする前は手動で期限切れアイテムを識別し、古いデータを削除しました。 これは労力と激しく計算を必要とし、テーブルのプロビジョニングされたスループットの一部も消費する必要がありました。 今は各アイテムの有効期限を設定し、あとはDynamoDBに任せます。 失効したデータは自動的に消え、使用可能なスループットには影響しません。 その結果、TUNEは85テラバイトの古いデータを削除することができ、年間200,000ドル以上のコストを削減し、アプリケーションロジックも簡素化しました。 知っておくべきこと あなたのアプリケーションにTTLを使用することを検討する際、留意すべきことがいくつかあります。 […]

みなさん、こんにちは。Partner SA 酒徳です。 本日、東京ミッドタウン カンファレンスホールにてAWS Partner Summit 2017 – Japan が開催され、昨年2016年の功績を讃え、APN Awardの授与式も同時に行われました。 APN Awardは一年を通し、各分野において最もパフォーマンスを発揮されたAPNパートナー様が受賞されるアワードで、今年は下記５つの分野において受賞パートナー様が選出されました。 APN Awardを授与されましたパートナー様とその授与内容についてご紹介させて頂きます。 – APN Partner of the Year 2016 年間を通じて営業・技術・マーケテイング分野等のパートナーとしての総合力で判断し、 AWSのビジネスに最も貢献いただいたAPNパートナー様が受賞 – APN Rising Star of the Year 2016 APNに加入して頂き1年目にして、AWSビジネスに最も高く貢献頂いたAPNパートナー様が受賞 – APN Cloud Business of the Year 2016 AWSが企業のビジネスに大きく貢献いただき、市場に大きな影響を与えたAPNパートナー様が受賞 – APN Architecture of the Year 2016 AWSの利用アーキテクチャがクラウド利用上優れているものの中から、最も先進的、実用的、チャレンジングなものをAWS のソリューションアーキテクトが選定。同システムを構築したAPNパートナー様が受賞 – APN Reference […]

リレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと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 など) を使用してインスタンスをカスタマイズできます。 […]

AWS re:Invent の初日に、私は EC2 インスタンスの更新に関する投稿で、入手次第、皆様に追加情報をお知らせすることを約束しました。本日は、15 か所の AWS リージョンで 6 つのサイズの新しい I3 インスタンスの提供を開始したことをお知らせします。このインスタンスは入出力量が多いワークロード用に設計されており、きわめて効率が高い NVMe SSD ストレージを備えています。4 KB ブロックで最大 330 万の IOPS を配信し、最大 16 GB/秒のシーケンシャルディスクスループットを実現します。このため、リレーショナルデータベース、NoSQL データベース、検索エンジン、データウェアハウス、リアルタイム分析、ディスクベースのキャッシュなど、高スループットと低レイテンシーを必要とするあらゆるワークロードに最適です。I3 インスタンスは、I2 インスタンスと比較すると、低コストで高密度のストレージを提供し、CPU コアあたりの IOPS とネットワーク帯域幅も大幅に増えます。 仕様 インスタンスサイズと関連仕様は次のとおりです。 インスタンス名 vCPU カウント メモリ インスタンスストレージ (NVMe SSD) 料金/時間 i3.large 2 15.25 GiB 0.475 TB 0.15 USD i3.xlarge 4 30.5 GiB 0.950 TB 0.31 USD […]