Amazon Web Services ブログ

これは、AWS Week in Review の 2 番目のコミュニティ型エディションです。 この実現に貢献してくれた 13 名の外部寄稿者に特に感謝します。 寄稿を希望される場合は、GitHub の AWS Week in Review をご覧ください。 関連するコンテンツの追加は、快適なご自分のウェブブラウザから迅速かつ簡単に行えます。 念のためですが、他者によって書かれたコンテンツを追加することもまったく問題ありません。 目標は、よく言われるように、すべてをキャッチすることです。 月曜日 8 月 29 日 CloudWatch ログとダッシュボードの改良を発表しました。 AWS Partner Network Blog は、楽しく簡単なスナップショットのためのスパースな EBS ボリュームの構築方法を説明しました。 [backspaceblog] は、アプリケーションのフロントエンドセキュリティ (「責任分担 2 – Dynamic CSS セレクタを使用して、ボットを停止する。」) について説明しました。 John McKim はサーバーレスアーキテクチャについて書きました。 Antoni Massó は、「AWS における ElastiCache (Memcached) ノードの自動検出の実装方法」のチュートリアルを共有しました。 火曜日 8 […]

Amazon Aurora はAWSサービスの中で最も速く成長するサービスになりました！ リレーショナルデータベースをクラウドに適したデザインにすることで(Amazon Aurora – Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!! の記事もご覧ください)、Aurora は大きなパフォーマンス改善や、64TBまでシームレスにスケールアップするストレージ、堅牢性・可用性の向上を実現しています。AuroraをMySQL互換にデザインすることによって、お客様は既存のアプリケーションの移行や新しいアプリケーションの構築を簡単に行って頂けています。 MySQL互換を保ちながら、そしてクラウドネイティブなAuroraアーキテクチャを活用することでAuroraには多くのイノベーションを加えられると考えています。 本日、3つのパフォーマンスを改善する新機能をAuroraに追加しました。それぞれの機能は、AWSをご利用の多くのお客様の一般的なワークロードでAuroraのパフォーマンスを改善するように設計されました。   Parallel Read Ahead – レンジ select、 フルテーブルスキャン、テーブル定義の変更やindex作成が最大5倍高速に Faster Index Build – indexの作成時間が約75%短縮 NUMA-Aware Scheduling – 2つ以上のCPUが搭載されているデータベースインスタンスをご利用の場合、クエリキャッシュからの読み込みやバッファキャッシュからの読み込みが速くなり、全体的なスループットが最大10%向上   詳細をご紹介します Parallel Read Ahead MySQLで利用されているInnoDBストレージエンジンは行やindex keyを利用するストレージ(ディスクページ)を管理します。これはテーブルのシーケンシャルスキャンの高速化や新しく作成されたテーブルに効果的です。しかし、行が更新・作成や削除されるにつれて、ストレージがフラグメントされることによって、ページは物理的にシーケンシャルではなくなってきます。そして、スキャン性能が大きく低下します。InnoDBのLinear Read Ahead機能はページが実際に利用されるまでメモリ内で64ページまでまとめることでフラグメントに対処しています。しかし、エンタープライズスケールのワークロードでは、この機能は有効な性能向上にはなりません。 今日のアップデートでは、Auroraは多くの状況で賢くこのような状況を扱う機能をご提供します。Auroraがテーブルをスキャンする際に、論理的に判断し、並列で追加のページをプリフェッチします。この並列プリフェッチはAuroraのレプリケーションが行われているストレージ(3つアベイラビリティゾーンにそれぞれ2つずつのコピー)で優位性を発揮し、データベースキャッシュ中のページがスキャンオペレーションに関連しているかを判断するのに役立ちます。 結果として、レンジselect、フルテーブルスキャン、ALTER TABLE そして、index作成を以前のバージョンと比較して最大5倍高速に行えるようになりました。 Aurora 1.7(詳細はこの後の情報をご覧ください)にアップグレードすることで、すぐにこのパフォーマンス改善をご体験頂けます。   Faster Index Build プライマリー、セカンダリーインデックスをテーブルに作成する時、ストレージエンジンは新しいキーを含んだ木構造を作成します。この処理は、多くのトップダウンのツリーサーチや、より多くのキーの増加に対応するためにツリーの再構築によりページ分割が伴います。 Auroraはボトムアップ戦略でツリーを構築します。リーフを最初に作成し、必要な親ページを追加していきます。この機能によりストレージ内の移動を軽減し、加えて各ページが一旦全て埋まるためページを分割する必要がなくなります。 この変更により、テーブルのスキーマによりますがindexの追加やテーブルの再構築が最大4倍高速になります。例として、Auroraチームが以下の様なスキーマでテーブルを作成し100億行を追加し5GBののテーブルを作製しました:   create table test01 (id […]

ビジネスをクラウドに移行する顧客が増えるに伴い、市場では、AWS でアプリケーションとインフラストラクチャを設計、デプロイ、運用できる熟練した IT プロフェッショナルの需要が高まっています。IT 認定資格は、技術的熟練度と職務遂行能力を検証するための究極の判断基準と考えられています。認定資格の取得は、IT プロフェッショナルにとって、キャリアアップにつながることがよくあります。個人がキャリアアップに目を向け、顧客が使用施設に関する知識とスキルを組織内に構築するに伴い、IT 認定資格の取得へと導くトレーニングがより重要になっています。 Global Knowledge は最近、2016 年 IT スキルおよび給与レポートをリリースしました（利用には登録が必要）。このレポートは、Global Knowledge の第 9 回年次 IT スキルおよび給与調査（この種では最大規模）における、北米の 10,000 人以上の IT およびビジネスプロフェッショナルからの回答に基づいています。Global Knowledge の調査結果では、トレーニングの重要性が明らかになり、AWS 認定資格取得者の価値も示されました。 トップ 5 の調査結果 以下に、今年のレポートで際立っていたトップ 5 の調査結果を取り上げます。 回答者の 4 分の 3 は、新しいスキルを構築するために何らかの形式の専門的能力開発トレーニングに参加したと答え、その半分は、キャリアの証明やスペシャリスト試験の準備が主な動機だと答えました。 総じて、IT プロフェッショナルの 59% は、何らかの形式の認定資格取得トレーニングに参加中か、今年中に参加予定です。 昨年に認定資格取得トレーニングに参加した回答者の 73% が、そのトレーニングにより仕事の有効性が上がったと答えました。 大幅な昇給（11% 以上）があったと報告した回答者の 21% は、付加価値として開発された新しいスキルがその要因だと答えました。 トレーニングプランのある組織の従業員は、会社を辞める可能性が低いと答えました（トレーニングプランのない組織では 73%、あるかどうかは不明な組織では 69% に対して、そのようなプランのある組織では 78%）。 これらは実に興味深い調査結果です。以下に、その概要をインフォグラフィック形式で示します（ご自由にお使いください）。 AWS […]

EC2 スポットフリートモデル（詳しくは「Amazon EC2 スポットフリート API – 1 回のリクエストで数千台のスポットインスタンスを制御」をご覧ください）では、1 回のリクエストで EC2 インスタンスのフリートを作成できます。お客様はフリートのターゲットキャパシティーを指定し、1 時間あたりの入札価格を入力して、フリートに含めるインスタンスタイプを選択するだけです。 バックグランドで、AWS は最安値のスポットインスタンスを起動することにより、必要なターゲットキャパシティー（インスタンスまたは仮想 vCPU の数で表記）を維持します。やがて、フリート内のインスタンスが価格上昇により終了されると、その時点で最安値の交換用のインスタンスが起動されます。 新しい Auto Scaling 今回、Auto Scaling の追加により、スポットフリートモデルが強化されました。Amazon CloudWatch メトリックスに基づいて、フリートをスケールアップ/ダウンできるようになりました。メトリックスには、EC2、Amazon EC2 Container Service、Amazon Simple Queue Service (SQS) などの AWS サービスのものを使用できます。代わりに、アプリケーションからパブリッシュしたカスタムメトリックスを使用して、Auto Scaling が開始されるようにもできます。いずれにせよ、これらのメトリックスを使用してフリートのサイズを制御することで、条件や負荷が変わったとしてもアプリケーションの可用性、パフォーマンス、コストをきめ細かく制御できます。以下に示しているのは、この機能の使用開始に必要ないくつかの概念です。 コンテナ – CPU やメモリの使用率メトリックスを使用して、Amazon ECS で動作しているコンテナベースのアプリケーションをスケーリングします。 バッチジョブ – SQS キュー内のメッセージ数に基づいて、キューベースのバッチジョブをスケーリングします。 スポットフリート – スポットフリートメトリックス（ MaxPercentCapacityAllocation など）に基づいて、フリートをスケーリングします。 ウェブサービス – 測定された応答時間と 1 […]

SAP HANAの大規模ワークロードにおける新しい利用方法をお伝えするために、私の同僚のSteven Jonesが寄稿してくれました。 — Jeff; AWSクラウド上でSAP HANAのような大規模なインメモリデータベースやインメモリアプリケーションを稼働させるため、Amazon EC2 メモリ最適化インスタンスファミリーに新しいX1インスタンスタイプとして、2TBのRAMを搭載したx1.32xlargeの利用開始を5月に発表しました。 X1インスタンスのシングルノード構成でのSAP HANAにおけるSAP認定取得を同時に発表し、それ以来、SAP S/4HANAとSuite on HANAといったOLTP、またBusiness Warehouse on HANAにBIといったOLAPにおける幅広い用途で、世界中の多くのお客様にご利用いただいています。とはいえ、クラスタ化されたX1インスタンスによるスケールアウト構成でのSAP HANAの提供のご要望も多くいただいていました。 SAP認定プロセスに応じたSAP HANAスケールアウト構成の広範囲なテストとベンチマークを終え、本日、高度に最適化された次世代データウェアハウスSAP BW/4HANAの新発表と同時に、X1インスタンスの最大7ノード、つまり14TBのRAMに対応したSAP BW/4HANAを含むOLAPシナリオの大規模スケールアウト構成におけるSAP認定取得を発表できることを嬉しく思います。 拡張性、柔軟性、コスト効果の高いSAP社の新しいフラッグシップのデータウェアハウスであるSAP BW/4HANAのローンチを私たちがサポートできることに非常に興奮しています。 以下は7台のX1インスタンスで稼働する大規模(14TBメモリ)なスケールアウト構成を表示したSAP HANA Studioのスクリーンショットです： そして、これはほんの始まりに過ぎません。私たちは他のサイズでのX1インスタンスを利用可能にする計画があり、より大きな50TBメモリまでのクラスタ構成を研究室でテストしています。もし、14TBメモリを超える大規模なスケールアウト構成が必要な場合は、ご支援しますので、ぜひご相談ください。 コストと複雑性の削減 多くのお客様が複数のR3インスタンスによるスケールアウト構成でSAP HANAを稼働してきました。今回の新しい認定により、コストと複雑性の両方が削減できる、より少ないインスタンス数での大規模スケールアウト構成に統合できる可能性があります。統合戦略における詳細はSAP HANA Migration Guideをご参照ください。 柔軟性のある高可用性オプション AWSプラットフォームでは、可用性が求められるSAP S/4HANAやSAP BW/4HANAのような環境で使われる重要なSAP HANAを保護するために、お客様のご要望に応じた様々なオプションを提供しています。実際に、従来型のホスティングプロバイダーやオンプレミスのスケールアウト構成でSAP HANAを稼働しているお客様からは、ハードウェア障害に迅速に対応できるように予備のハードウェアやスタンバイノードを購入し非常に高額なメンテナンス契約料を支払わなければならない、とよくお伺いします。他には、残念ながら、何も起こりませんようにと祈って、この余分なハードウェアをなしで済ませようとされています。 AWSプラットフォーム上で活用されている便利なオプションの一つは、Amazon EC2 Auto Recoveryと呼ばれるソリューションです。AWSに起因するハードウェア障害や問題が発生したときに自動的に正常なホスト上で復旧するよう、EC2インスタンスを監視するAmazon CloudWatch アラームを簡単に作成できます。復旧されたインスタンスは、アタッチされたEBSボリュームやホスト名、IPアドレス、AWSインスタンスIDなどの構成情報も元のインスタンスと同じものです。Amazon CloudWatchの標準料金(例えば、米国東部では月当たりアラームごとに0.10ドル)が適用されます。実質、ハードウェア異常への迅速な復旧のために、私たちの持つ空いているキャパシティをすべてお客様の予備機として活用することが可能です。 開始方法 最新のAWS Quick Start Reference Deployment for SAP HANAを使うことで、十分にテストされたX1インスタンスでのシングルノード構成、およびスケールアウト構成のSAP […]

2 回目のゲスト投稿で触れたように、Tina Barr 氏がさらに 4 つのホットスタートアップについてお話します。 — Jeff; 今月は、AWS による 4 つのホットスタートアップを取り上げます。 Craftsvilla – 民芸品を購入できるプラットフォームを提供しています。 SendBird – 開発者が 1 対 1 メッセージングとグループチャットをすばやく構築できるようにしています。 Teletext.io – システムが不要なコンテンツ管理ソリューションです。 Wavefront – クラウドベースの分析プラットフォームです。 Craftsvilla Craftsvilla は、インドの工芸品、芸術、文化に対する純粋な愛と感謝のゆえに 2011 年に誕生しました。西インドのグジャラート地域を車で旅しているとき、Monica Gupta 氏と Manoj Gupta 氏は、地元の職人が作る美しい作品に魅了されました。しかし、それらの職人たちが生計を立てるのに苦労していることに 2 人共驚きの色を隠せませんでした。Monica 氏と Manoj 氏は、高い技術を持った職人たちが消費者と直接つながり、より広範なオーディエンスにリーチできるプラットフォームの作成に着手しました。本物の民芸品には、世界中で非常に大きな需要がありますが、消費者がふさわしい購入先を見つけられないことがよくあります。Craftsvilla は、この問題の解決を支援しています。 インドの文化はとても豊かで多様性に富んでいるため、だれも 1 つのプラットフォームに取り込もうとはしてきませんでした。Craftsvilla は、技術革新を利用して、衣料品、アクセサリー、ヘルス & ビューティー製品、食料品、室内装飾すべてを、簡単にアクセスできる 1 つのスペースにまとめています。たとえば、さまざまな衣類 (サルワールスーツ、サリー、レヘンガ、カジュアルウェア) を提供するだけでなく、それらの各カテゴリをさらにサブカテゴリに分けています。消費者は、ニーズに合ったものを見つけることができます。素材、スタイル、状況、さらには作品のタイプ (刺しゅう、ビーズ、クリスタル製品、手作りなど) […]

Amazon CloudWatch では AWS インフラストラクチャで発生する問題の確認、診断、対応、解決を AWS で実行しているアプリケーション内で行うことができます。今回は CloudWatch Logs (Store and Monitor OS & Application Log Files with Amazon CloudWatch) そして CloudWatch ダッシュボード (CloudWatch Dashboards – Create & Use Customized Metrics Views) に追加された複数のユーザビリティと機能の改善点についてご説明します。 CloudWatch Logs のユーザビリティを改善 CloudWatch Logs はオペレーティングシステムやアプリケーションログファイルを管理する、可用性と拡張性そして耐久性が高く安全なサービスです。ログのデータ取り込み、保管、フィルター、検索、アーカイブを可能にするため、操作の負荷を軽減しアプリケーションとビジネスに集中できるようにします。ログの件数やサイズが増えても効率性と生産性を維持できるようにするため、AWS では CloudWatch Logs コンソールにユーザビリティの改善点をいくつか加えました。 ログデータのフォーマット処理を改善 長いログファイルへのアクセスを簡略化 ロググループ内の検索が簡単に ログファイルの共同作業を簡易化 特定の期間内の検索を改善 今回のリリース前に CloudWatch ダッシュボードにも改善点を加えました。 フルスクリーンモード ダークテーマ グラフ内にある Y 軸の範囲を指定 […]

以前より、AWS の多くのお客様からプログラムを使用してコストや使用状況レポートを分析する方法をリクエスト頂いていました (詳しくは New – AWS Cost and Usage Reports for Comprehensive and Customizable Reporting をご覧ください)。リクエストをお寄せくださったお客様は、いくつものリージョンにわたり AWS を使用して複数のビジネスを行い、幅広く様々なサービスをご利用されている傾向があります。AWS では請求レポートやコストに関する詳細情報をご提供しているため、これはビッグデータに関与する問題であり、AWS サービスを使用すれば簡単に解決することができます。今月初旬に私が休暇を取っていた間に、AWS はコストや使用状況レポートを Amazon Redshift や Amazon QuickSight にアップロードできる新機能をリリースしました。今回はその新機能についてご説明します。 Redshift にアップロード まず、新しい Redshift クラスターを作成してみました (すでに実行しているクラスターがある場合は新たに作成する必要はありません)。私が作成したクラスターは次の通りです。 次に請求レポート機能が有効になっていることを確認しました。 そしてコストと請求レポートに行き、Create report をクリックしました。 次にレポート名を指定 (MyReportRedshift) し、時間制に設定してから Redshift と QuickSight 両方のサポートを有効にしました。 最後に配信オプションを選択しました。 次のページでレポートを作成することを確認し、Review and Complete をクリックしました。レポートが作成され、最初のレポートは 24 時間以内にバケットに届くという通知が届きました。 待機している間に PostgreSQL を EC2 インスタンス […]

AWS では毎日なにかしら興味深いことが起きていることに私が気付いたのは 2012 年のことでした。市販用にパッケージされたソフトウェアの流通が一般的だったその当時、クラウドは着実にそして継続的に、その開発を進行させていました。このブログをご覧の皆さんに、すべてのアクティビティをご説明するため、そして AWS が開発するイノベーションのペースについて分かりやすく解説するために、2012 年の春、初の AWS ウィークリーレビューを公開しました。初回、ブログをまとめフォーマットを作り投稿するまでのプロセスに掛かった時間は約 5 分ほどでした。公開後、読者の皆さんから素晴らしいフィードバックをお寄せ頂き、その後 4 年間に渡り毎週新しいブログを投稿してきました。そして時間が経つに連れて AWS はもちろん、次第に規模が大きくなっていった AWS ファンのコミュニティ、開発者、パートナーからのコンテンツによる内容も増えていきました。しかし残念なことに、ウィークリーレビューを公開していくために情報を探し保存そしてリンクをフィルターして投稿という流れに大きく時間を取られるようになっていきました。今年の始めに公開した 4 月 25 日付けのウィークリーレビューを書き上げるには 4 時間も時間を費やすことになり、残念ながらウィークリーレビューの投稿は、その週をもって中止することに決定しました。その後、読者の皆様から何件ものメールやツイートを頂き、よりオープンでスケーラブルな新しいモデルを使用したレビュー再開の可能性について検討することにしました。 協力者の幅を拡大 そしてこの度、AWS ウィークリーレビューが GitHub プロジェクトとして復活することになりました (https://github.com/aws/aws-week-in-review)。これに伴い寄稿者のお誘い (AWS ファン、ユーザー、ブロガー、パートナー) をスタートします。流れとしては、毎週月曜日の朝、私が前週のプルリクエストをレビューしてから承認、その週のウィクーリーレビューを午前 10 時 (太平洋標準時) までに公開します。投稿内容の目的と質を維持するため、スタイルやコンテンツがガイドラインに適しているプルリクエストを私が承認します。その時点で私が次週のファイルも作成するので、ご自分に関係性のある新しいコンテンツを検索し表示することができます。 コンテンツとスタイルのガイドライン 寄稿者に該当するガイドラインは次の通りです。 関連性 – 寄稿する内容はすべて AWS に直接関連していること。 所有権 – 寄稿内容の所有権は寄稿者が持つこと。 有効性 – リンクはすべて一般公開されている内容であること (無料およびゲートしているコンテンツは問題なし)。 適時性 – 寄稿した内容はすべて関連の日付に作成されたものであること。 中立性 – […]

これは、AWS Week in Review の最初のコミュニティ型エディションです。先週のブログ投稿 (AWS Week in Review – Coming Back With Your Help!) にお応えして、他の 9 名の寄稿者がこの投稿を現実のものとしてくれました。すばらしいスタートです。今週は 20 件にいくかどうか見てみましょう。 月曜日 8 月 22 日 AWS Government, Education, & Nonprofits Blog は、Acquia (APN テクノロジーパートナー) がどのように AWS を利用して FedRAMP コンプライアンスを実現しているかについて説明しました。 [backspaceblog] は、アプリケーションのフロントエンドセキュリティ (「Shared Responsibility – Stopping threats at the source」) と、脅威が AWS に到達することを防ぐためにアプリケーションで使用できる技術について説明しました。 AWS Cloudability Blog […]