Author: AWS Japan Staff


Amazon Auroraアップデート – Parallel Read Ahead, Faster Indexing, NUMA Awareness

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 int not null auto_increment primary key, i int, j int, k int);

そして4つのindexを追加しました

alter table test01 add index (i), add index (j), add index (k), add index comp_idx(i, j, k);

db.r3.largeインスタンスで、このクエリの実行時間が67分から25分になりました。db.r3.8xlargeでは、29分から11.5分に短縮されました。

これは新機能でプロダクション環境以外でのテストをお勧めします。利用するには、Aurora 1.7へアップグレードを行ない DB Instance Parameter group(詳細は DB Cluster and DB Instance Parametersをご覧ください)でaurora_lab_mode1に設定します。

rds_aurora_set_lab_mode

Auroraチームはこのパフォーマンス改善に対するみなさまからのフィードバックを楽しみにしています。お気軽にAmazon RDS Forumへ投稿をお願いします。

 

NUMA-Aware Scheduling

最も大きいデータベースインスタンス(db.r3.8xlarge) は2つのCPUを搭載しNUMA(Non-Uniform Memory Access)と呼ばれる機能を持っています。このタイプのシステムでは、メインメモリの各区画は各CPUに直接効率的にアクセス出来ます。残りのメモリは少し非効率なCPU間のアクセス経路を介してアクセスします。

Auroraはこの不均等なアクセス時間を活用するためにスケジューリングスレッドのjobを効率的に扱うことが可能になりました。スレッドは他のCPUに接続されている非効率なメモリへのアクセスを気にする必要がありません。結果として、クエリキャッシュやバッファキャッシュを大量に利用する様なCPUバウンドな操作で最大10%性能が向上しました。パフォーマンス向上は同じデータベースインスタンスに数百または数千接続を行っているときに顕著に発揮します。例として、Sysbench oltp.lua ベンチマークで570,000 reads/secondから625,000 reads/secondに向上しました。このテストではdb.r3.8xlarge DBインスタンスで以下のパラメータを利用して行いました。

  • oltp_table_count=25
  • oltp_table_size=10000
  • num-threads=1500

Aurora 1.7にアップグレードすることで、すぐにこのパフォーマンス改善をご体験頂けます。

 

Upgrading to Aurora 1.7

新しく作成されたDBインスタンスはAurora 1.7で自動的に起動します。既に起動しているDBインスタンスでは、update immediately か during your next maintenance windowを選択することでインストールが可能です。

以下のクエリでAurora 1.7で起動しているか確認出来ます。

mysql> show global variables like “aurora_version”;
+—————-+——-+
| Variable_name | Value |
+—————-+——-+
| aurora_version | 1.7 |
+—————-+——-+

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

 

インフォグラフィック – トップ 5 の調査結果: Global Knowledge の IT スキルおよび給与レポート

ビジネスをクラウドに移行する顧客が増えるに伴い、市場では、AWS でアプリケーションとインフラストラクチャを設計、デプロイ、運用できる熟練した IT プロフェッショナルの需要が高まっています。IT 認定資格は、技術的熟練度と職務遂行能力を検証するための究極の判断基準と考えられています。認定資格の取得は、IT プロフェッショナルにとって、キャリアアップにつながることがよくあります。個人がキャリアアップに目を向け、顧客が使用施設に関する知識とスキルを組織内に構築するに伴い、IT 認定資格の取得へと導くトレーニングがより重要になっています。

Global Knowledge は最近、2016 年 IT スキルおよび給与レポートをリリースしました(利用には登録が必要)。このレポートは、Global Knowledge の第 9 回年次 IT スキルおよび給与調査(この種では最大規模)における、北米の 10,000 人以上の IT およびビジネスプロフェッショナルからの回答に基づいています。Global Knowledge の調査結果では、トレーニングの重要性が明らかになり、AWS 認定資格取得者の価値も示されました。

トップ 5 の調査結果
以下に、今年のレポートで際立っていたトップ 5 の調査結果を取り上げます。

  1. 回答者の 4 分の 3 は、新しいスキルを構築するために何らかの形式の専門的能力開発トレーニングに参加したと答え、その半分は、キャリアの証明やスペシャリスト試験の準備が主な動機だと答えました。
  2. 総じて、IT プロフェッショナルの 59% は、何らかの形式の認定資格取得トレーニングに参加中か、今年中に参加予定です。
  3. 昨年に認定資格取得トレーニングに参加した回答者の 73% が、そのトレーニングにより仕事の有効性が上がったと答えました。
  4. 大幅な昇給(11% 以上)があったと報告した回答者の 21% は、付加価値として開発された新しいスキルがその要因だと答えました。
  5. トレーニングプランのある組織の従業員は、会社を辞める可能性が低いと答えました(トレーニングプランのない組織では 73%、あるかどうかは不明な組織では 69% に対して、そのようなプランのある組織では 78%)。

これらは実に興味深い調査結果です。以下に、その概要をインフォグラフィック形式で示します(ご自由にお使いください)。

AWS トレーニング & 認定資格
参考までに、AWS には現在、ソリューションアーキテクト、システムオペレーション管理者、開発者、開発オペレーションエンジニアの職務を対象とした、5 つの認定資格があります。AWS はまた、一連のテクニカルトレーニングコースなど、試験の準備に役立つ手段を提供しています。受講希望がセルフペースのオンラインラボでも、テクニカルインストラクター主導のクラスでも、皆様のニーズに合ったトレーニングをご用意しています。

Global Knowledge は、世界中で AWS トレーニングの提供を認められている多くの APN トレーニングパートナーの 1 社です。オンサイトトレーニングの申し込みについては、AWS グローバルクラス一覧で受講可能なクラスを検索するか、こちらまでお問い合わせください。

Jeff;

新機能 – EC2 スポットフリートの Auto Scaling

EC2 スポットフリートモデル(詳しくは「Amazon EC2 スポットフリート API – 1 回のリクエストで数千台のスポットインスタンスを制御」をご覧ください)では、1 回のリクエストで EC2 インスタンスのフリートを作成できます。お客様はフリートのターゲットキャパシティーを指定し、1 時間あたりの入札価格を入力して、フリートに含めるインスタンスタイプを選択するだけです。

バックグランドで、AWS は最安値のスポットインスタンスを起動することにより、必要なターゲットキャパシティー(インスタンスまたは仮想 vCPU の数で表記)を維持します。やがて、フリート内のインスタンスが価格上昇により終了されると、その時点で最安値の交換用のインスタンスが起動されます。

新しい Auto Scaling
今回、Auto Scaling の追加により、スポットフリートモデルが強化されました。Amazon CloudWatch メトリックスに基づいて、フリートをスケールアップ/ダウンできるようになりました。メトリックスには、EC2、Amazon EC2 Container ServiceAmazon Simple Queue Service (SQS) などの AWS サービスのものを使用できます。代わりに、アプリケーションからパブリッシュしたカスタムメトリックスを使用して、Auto Scaling が開始されるようにもできます。いずれにせよ、これらのメトリックスを使用してフリートのサイズを制御することで、条件や負荷が変わったとしてもアプリケーションの可用性、パフォーマンス、コストをきめ細かく制御できます。以下に示しているのは、この機能の使用開始に必要ないくつかの概念です。

  • コンテナCPU やメモリの使用率メトリックスを使用して、Amazon ECS で動作しているコンテナベースのアプリケーションをスケーリングします。
  • バッチジョブSQS キュー内のメッセージ数に基づいて、キューベースのバッチジョブをスケーリングします。
  • スポットフリート – スポットフリートメトリックス( MaxPercentCapacityAllocation など)に基づいて、フリートをスケーリングします
  • ウェブサービス – 測定された応答時間と 1 秒あたりの平均リクエスト数に基づいて、ウェブサービスをスケーリングします。

スポットフリートコンソール、AWS Command Line Interface (CLI)、または AWS CloudFormation を使用するか、AWS SDKs のいずれかにより API 呼び出しを行うことで、Auto Scaling を設定できます。

私はフリートの起動から始めました。フリートをスケールアップ/ダウンできるようにするために、リクエストタイプとして [Request and Maintain] を使用しました。

フリートは 1 分ほどで稼働状態になりました。

続いて、例示用に SQS キューを作成し、いくつかのメッセージをそのキューに入れて、CloudWatch アラーム(AppQueueBackingUp)を定義しました。このアラームは、キューに 10 件以上のメッセージが入ると起動されます。

また、アラーム(AppQueueNearlyEmpty)も定義しました。このアラームは、キューが空になりそう(メッセージが 2 件以下)になると起動されます。

最後に、このアラームをフリートの ScaleUpScaleDown のポリシーにアタッチしました。

この記事を書き始める前に、SQS キューに 5 件のメッセージを入れました。フリートを起動して、スケーリングポリシーを設定してから、さらに 5 件のメッセージを追加して、アラームが起動されるのを待ちました。

その後、フリートにチェックインすると、キャパシティーが想定どおりに増加したことがわかりました。この結果は [History] タブに表示されました("New targetCapacity: 5")。

仕上げとして、キューからすべてのメッセージを消去し、植物の水やりをして戻ると、フリートが想定どおりスケールダウンされたことがわかりました("New targetCapacity: 2")。

今すぐ利用可能
この新機能は、スポットインスタンスがサポートされているすべてのリージョンで、今すぐ利用し始めることができます。

Jeff;

新発表 – X1インスタンスのクラスタによるSAP HANAの稼働

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 HANAの本稼働環境を1時間もかからずにご利用いただけます。

Amazon Web Services上でのSAP HANAの導入を計画される際には、ベストプラクティスとガイダンスとしてSAP HANA Implementation and Operations Guide もご確認ください。

AWSとSAPのエキサイティングな共同発表に立ち合いに、9月7日にベイエリアにいらっしゃいませんか?ここから登録いただき、サンフランシスコでお会いしましょう!

来られないでしょうか?SAPをご利用のお客様にAWSとSAP社が共同でご提供する価値を知っていただくためにも、太平洋標準時で9月7日朝7時から9時のライブストリーミングにご参加ください。

皆様のご参加をお待ちしております。

Steven Jones, Senior Manager, AWS Solutions Architecture

翻訳はPartner SA 河原が担当しました。原文はこちらです。

各国のAWS ホットスタートアップ – 2016 年 8 月

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 つのスペースにまとめています。たとえば、さまざまな衣類 (サルワールスーツサリーレヘンガ、カジュアルウェア) を提供するだけでなく、それらの各カテゴリをさらにサブカテゴリに分けています。消費者は、ニーズに合ったものを見つけることができます。素材、スタイル、状況、さらには作品のタイプ (刺しゅう、ビーズ、クリスタル製品、手作りなど) によって製品をフィルタリングできます。新しい料理に挑戦したくなったときも、Craftsvilla がお手伝いします。マサラから伝統的なスイーツ、おいしい紅茶ブレンドまで、興味深い製品が何百も揃っています。インドのさまざまな地域ごとにフィルタリングして新しい食べ物を発見するオプションも用意されています。

Craftsvilla で販売者になるのは簡単です。店舗のオーナーは、無料アカウントを作成するだけで、ユニークな製品やサービスの販売を開始することができます。Craftsvilla の最終的なビジョンは、あらゆる民芸品の「ワンストップの目的地」となることです。着々とその道を進もうとしています。

AWS 自体は、Craftsvilla のチームにおけるエンジニアです。カスタマーエクスペリエンスは、同社の従業員にとってとても重要であり、拡張性と効率性を同時に実現することはビジネスにとって不可欠な部分です。インフラストラクチャを大規模に自動化しています。AWS を利用せずに現在のペースで行うことは不可能です。現在同社は、Amazon Elastic Compute Cloud (EC2)Elastic Load BalancingAmazon KinesisAWS LambdaAmazon Relational Database Service (RDS)Amazon RedshiftAmazon Virtual Private Cloud など、20 を超える AWS Service を利用しています。同社のアプリ QA プロセスは AWS Device Farm に移行され、Lambda のおかげで 250 以上のサービスにおいてクラウド上で完全に自動化されます。Craftsvilla は、ウェブサービスから分析まで、インフラストラクチャのあらゆるニーズを AWS に完全に依存しています。

詳細については、Craftsvilla のブログをご覧ください。

SendBird
最初のスタートアップを成功させた後、SendBird の創立者である John S. Kim 氏、Brandon Jeon 氏、Harry Kim 氏、Forest Lee 氏は、コンシューマーアプリ開発者にとって大きな市場機会を見つけました。現在、eBay、Nexon、Beat、Malang Studio、SK Telecom などの 2,000 を超えるグローバル企業が、SendBird を使用してモバイルアプリやウェブサイトにチャットおよびメッセージング機能を実装しています。企業は、次のような方法で SendBird を使用しています。

  • プライベートメッセージングや会話取引用の 1 対 1 メッセージング
  • 友人や共通の目的を持グループでのグループチャット
  • ライブビデオストリームやゲームコミュニティにおける大規模なチャットルーム

メッセージングが世界的な現象となるのを見たとき、SendBird の創立者たちはアプリ開発者がテクノロジースタックを一から構築することには意味がなくなったことに気付きました。Localytics のデータチームによる調査は、実際にアプリ内メッセージングによりアプリの起動が 27% 増加し、エンゲージメントが 3 倍になることを示していますSendBird SDK (iOS、Android、Unity、.NET Xamarin、JavaScript で利用可能) をダウンロードするだけで、アプリおよびウェブ開発者はリアルタイムのメッセージング機能をわずか数分で実装できます。SendBird には、フルチャット履歴も備わっており、ユーザーはチャットメッセージの送信だけでなく、ファイルとデータの転送をも行うことができます。さらに、開発者は、ライブブロードキャスト中にモバイルデバイスにメッセージが表示される速度を制御するスマートスロットリングなどの革新的な機能を統合できます。
アクセラレーター Y Combinator W16 Batch を卒業してから、同社のチャットユーザーは数か月以内に月 1,000,000 人から月 5,000,000 人に増加しました。また、ライブビデオストリーミング、ゲーム、e コマース、コンシューマーアプリにおいて毎日数百万もの新しいメッセージを処理しています。消費者は、短期間にデプロイできるリアルタイムのチャット API および SDK のために、あらゆる機能を備えたクロスプラットフォームのスタック全体アプローチを採用することに価値を見出しました。

SendBird は、世界中に分散した非常に大きなユーザーベースを処理する堅牢で拡張性の高いインフラストラクチャを構築するため、AWS を選択しました。EC2 とともに Elastic Load Balancing および Auto ScalingRoute 53S3, ElastiCacheAmazon AuroraCloudFrontCloudWatchSNS を利用しています。同社は、効率性と信頼性の高い拡張を行うため、AWS と連携し続ける予定です。

ぜひ SendBird と同社のブログをご覧ください。

Teletext.io
Teletext.io の共同創立者である Marcel Panse 氏と Sander Nagtegaal 氏は、複数のスタートアップにおいて連携し、それぞれ同じ問題を経験しました。カスタムソフトウェア開発の段階で、コンテンツ管理にかなり苦労するという点です。タイプミスなどのごく小規模な修正にも、通常は開発者が必要となるため、時間の経過とともにコストが膨れ上がります。Marcel 氏と Sander 氏は、すぐに利用できる適切なソリューションが見つからなかったため、この問題をついに解決する独自サービスを作ることにしました。API GatewayLambda 関数、Amazon DynamoDBS3CloudFront を活用するだけで、ドロップインコンテンツ管理サービス (CMS) を構築できました。CMS の新たな選択肢としてそのサーバーレスアプローチは、すぐに他の企業を引き付けたため、自身のニーズを満たすために使用するつもりであったにもかかわらず、2 人はそのアイデアを製品として売り出すことにし、Teletext.io が生まれました。

現在、Teletext.io はシステムが不要なコンテンツ管理ソリューションと呼ばれています。コンテンツディストリビューターは、プログラマーの助けを借りなくても、ウェブサイトやユーザーインターフェイスから直接 WYSIWYG エディターを通じてテキストとイメージを編集できます。次の 3 つのステップだけですぐに使い始めることができます。

  1. Teletext.io スクリプトを追加する。
  2. データ属性を追加する。
  3. ログインして入力し始める。

これで完了です。 開発者がシステムをインストールしたり、保守したりする必要はありません。Teletext.io はそのままの状態ですぐに動作します。繰り返し生じるコンテンツ更新に加えて、ローカライズの目的でデータ属性技術も使用できます。CMS を通じてウェブサイトを多言語にすると数日から数週間かかることがありますが、Teletext.io はわずか数分でこのタスクを成し遂げます。時間の節約は、開発者にとっても編集者にとってもメリットとなる重要な要素です。

Teletext.io は、さまざまな方法で AWS を利用しています。同社は、他社のウェブサイトコンテンツを扱っているため、外部のコンテンツがロードされているとウェブサイト訪問者が気付くことがないように、非常に高速で信頼性の高いシステムを必要としています。加えて、このクリティカルなインフラストラクチャサービスが停止することは許されません。どちらの要件を満たすためにも、可動部分ができる限り少ない堅牢なアーキテクチャが必要です。そのため、Teletext.io はサーバーレスアーキテクチャを運用することで一歩抜け出したサービスを提供しています。ドラフトコンテンツのロード、編集内容とイメージの保存、結果の公開において、Amazon API Gateway が呼び出され、AWS Lambda 関数がトリガーされます。Lambda 関数は、そのデータを Amazon DynamoDB に保存します。

Teletext.io のユニークなサーバーレスアプローチについては、同社のブログ投稿をご覧ください。

Wavefront
パロアルトで 2013 年に設立された Wavefront は、1 秒あたり数百万ものポイントで時系列データを保存するクラウドベースの分析プラットフォームです。ハイブリッドおよびクラウドインフラストラクチャにおいて、異常が発生する前に「通常」からの逸脱を検出することができます。これは、Lyft、Okta、Yammer、Box などの企業がスムーズな運営を維持するために利用している重要なサービスです。データ科学者から製品マネージャー、新興企業から Fortune 500 企業まで、Wavefront は強力なクエリエンジンとあらゆるユーザー向けに設計された言語を提供しています。

Wavefront では、従量課金制モデルを採用しているため、顧客は必要なアプリケーションサイズから始め、必要に応じて柔軟に拡張/縮小することができます。さらに、その料金にはエンタープライズクラスサポートが含まれており、追加費用はかかりません。Wavefront が顧客をどのようにサポートしているかについては、製品デモをご覧ください。

Wavefront アプリケーションはすべてが AWS にホストされており、AWS 内の Virtual Private Cloud (VPC) クラスターでシングルテナントインスタンスとマルチテナントインスタンスを運用しています。このアプリケーションは、CloudWatch および CloudTrail と緊密にネイティブ統合されているため、同様に AWS を利用している大規模顧客の多くにとってメリットとなります。Wavefront は、AWS を利用して「ソフトウェアの問題」を作り出し、独自のアプリケーションを使用したクラウドの運用、自動化、モニタリングを行っています。最も重要な点として、AWS により Wavefront は世界最高のエンタープライズクラウドモニタリングシステムを構築するというコアビジネスに集中することができます。

Wavefront について詳しくは、同社のブログ投稿「How Does Wavefront Work」をご覧ください。

Tina Barr

CloudWatch Logs とダッシュボードを改善

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 軸の範囲を指定
  • グラフ名の変更を簡易化
  • グラフ設定の永続的なストレージ

CloudWatch Logs コンソールの動作
では、次にそれぞれの改善点について詳しくご説明します。CloudWatch Logs コンソールを開き、ロググループをクリックしてからグループ内のログストリームにアクセスします。右側のオプションを表示メニューを見つけます。

次のように、複数行で拡大した状態でログメッセージを表示するにはすべて開くをクリックします。

飾りのないプレーンテキストでログを表示したい場合は、テキスト表示を切り替えることもできます。

この他にもロググループ内のストリームすべてに渡り、ログデータの表示を改善しました。ロググループを選びイベントを検索をクリックすると、そのロググループ内のストリームすべてからのログデータを見ることができます。例えば、1 つの Lambda 関数における複数の呼び出しに対する課金対象期間を見つけやすくなりました。

さらに、従来の割り付け表示に代わり、制限のないスクロールバーが導入されました。これでお好きなだけログファイルをスクロールできるようになりました。

次のように、特定の期間を指定したり、ワンクリックで日付を指定するなどして検索条件を絞り込むことが可能になりました。

チームの一員として作業をしている場合は、ご自分のログ分析セッションの URL を共有できるようになりました。
URL には検索パラメータとフィルターが含まれ、次のようなフラグメントもその一部になっています。

group=<log_group_name>_log;stream=<log_stream_name>;filter=<filter_parameter>;start=PT<time_frame>

この CloudWatch Logs コンソールの改善点は、今すぐご利用いただけます。詳しくは Getting Started with CloudWatch Logs をご覧ください。

CloudWatch ダッシュボードに追加した改善点
CloudWatch ダッシュボードに最近追加された改善点については、すでにお気づきの方もいらっしゃるかもしれません。まず、ダッシュボードに新しいフルスクリーンモードを追加しました。Actions メニューで全画面表示に切り替えるをクリックします。

フルスクリーンモード状態になったら、ダークをクリックして夜用の新しいダークテーマに切り替えることができます。

フルスクリーンモードでダークテーマを使用した Redis ダッシュボードの例がこちらです。

場合によってはダッシュボードにグラフをどのように表示するか、より細かに管理したいと思うこともあるのではないでしょうか。例えば、データの異常値がグラフを読みにくくしていて、ダッシュボードで Y 軸の特定範囲に集中したい場合などが考えられます。次の例はその場合のグラフです。異常値が急増した後に起きる傾向をマスクしています。

Y 軸を編集するには、ツールセレクターをクリックして Edit をクリックします。

Graph Options を選択し、お好きな具合にグラフが表示されるまで Y 軸の値を編集します。その後、ウィジェットの更新をクリックしてください。

編集後のグラフは次のようになります。

AWS の多くのお客様はダッシュボード内でグラフ名の変更ができるようにしたいとリクエストしていました。そして今回より、ワンクリックでその操作が可能になりました (グラフ名の近くにマウスを移動させ、鉛筆のアイコンをクリックするだけです)。

今後は CloudWatch が時間範囲、タイムゾーン設定、更新間隔、自動更新の設定を各グラフごとに記憶できるようになりました。

Amazon CloudWatch パートナーエコシステム
では最後に AWS パートナーによる優れたソリューションについてご紹介します。次のパートナーは CloudWatch に加え、付加価値のあるソリューションも構築しています。

  • DataDog はインフラストラクチャ内の主要項目との統合を提供し、問題対応の際に直接チームと協力することを可能にしています。
  • Librato はインフラストラクチャの要素に渡り統合を提供し、複合メトリックスや算術演算の時列系データへの変換をサポートしています。
  • SignalFx はメトリックスへの瞬時な可視性の提供、データ分析に集中そしてサービス規模で通知を送信しています。
  • Splunk はマシンデータの収集やインサイト検知を可能にするオペレーショナルインテリジェンスのプラットフォームを提供しています。
  • Sumo Logic はログ管理や時系列メトリックスのマシンデータ分析サービスで、アプリケーションの構築、実行、安全性の確保に役立っています。

ご自分が AWS パートナーでこちらのリストに属すものを提供していらっしゃる場合は、すぐに更新しますのでお知らせください。

Jeff;

新発表 – Redshift や QuickSight で AWS のコストや使用状況レポートのアップロードが可能に

以前より、AWS の多くのお客様からプログラムを使用してコストや使用状況レポートを分析する方法をリクエスト頂いていました (詳しくは New – AWS Cost and Usage Reports for Comprehensive and Customizable Reporting をご覧ください)。リクエストをお寄せくださったお客様は、いくつものリージョンにわたり AWS を使用して複数のビジネスを行い、幅広く様々なサービスをご利用されている傾向があります。AWS では請求レポートやコストに関する詳細情報をご提供しているため、これはビッグデータに関与する問題であり、AWS サービスを使用すれば簡単に解決することができます。今月初旬に私が休暇を取っていた間に、AWS はコストや使用状況レポートを Amazon RedshiftAmazon QuickSight にアップロードできる新機能をリリースしました。今回はその新機能についてご説明します。

Redshift にアップロード
まず、新しい Redshift クラスターを作成してみました (すでに実行しているクラスターがある場合は新たに作成する必要はありません)。私が作成したクラスターは次の通りです。

次に請求レポート機能が有効になっていることを確認しました。

そしてコストと請求レポートに行き、Create report をクリックしました。

次にレポート名を指定 (MyReportRedshift) し、時間制に設定してから Redshift と QuickSight 両方のサポートを有効にしました。

最後に配信オプションを選択しました。

次のページでレポートを作成することを確認し、Review and Complete をクリックしました。レポートが作成され、最初のレポートは 24 時間以内にバケットに届くという通知が届きました。

待機している間に PostgreSQL を EC2 インスタンス (sudo yum install postgresql94) にインストールし、 Amazon QuickSight プレビューで登録済みであることを確認しました。また、Create an IAM Role の指示に従って、読み取り専用の IAM ロールを作成しその ARN もキャプチャしました。

Redshift コンソールでは、Manage IAM Roles をクリックし ARN を自分の Redshift クラスターと関連付けました。

翌日、予定通りにバケットにファイルが到着したことを確認してから、Redshift にアクセスできるようにヘルパーファイルを取得するためコンソールにアクセスしました。

Redshift ファイルをクリックし、SQL コマンドをコピーしました。

ARN と S3 リージョン名を SQL に挿入しました(予想通りにクエリが作動するようにするため、リージョン名に引用符を使用する必要がありました)。

次に psql を使用して Redshift に接続しました (任意のビジュアルまたは CLI ベースの SQL クライアントの使用が可能)。

$ psql -h jbcluster.XYZ.us-east-1.redshift.amazonaws.com \
  -U root -p 5439 -d dev

SQL コマンドを実行しました。これで 1 組のテーブルが作成され、S3 から請求データをインポートしました。

Redshift でのデータのクエリ
手始めに同僚が提供してくれたいくつかのクエリを使用して、今月の S3 使用量を計算してみました。

AZ ベースのコストを見てみました。

次に AZ ごと、サービス別に見てみました。

試しに Redshift コンソールも少し調べてみました。すると、私のクエリをすべて見ることができました。

QuickSight のデータ分析
Amazon QuickSight を使ってコストや請求データも分析してみました。ログインしてから Connect to another data source or upload a file をクリックしました。

次に S3 バケットにアクセスし (jbarr-bcm) マニフェストファイルの URL をキャプチャ (MyReportRedshift-RedshiftManifest.json) しました。

データソースとして S3 を選択し URL を入力しました。

QuickSight は数秒内でデータをインポートし、新しいデータソースが利用可能になりました。SPICE (QuickSight のインメモリ計算エンジン) にロードしました。3 回から 4 回のクリックで AZ には関係のないデータを除外し AZ 特有のデータだけに集中することができました。

もう一度クリックして円グラフの表示に切り替えました。

サービス別のコストも調べてみました。

ご覧のように、新しいデータと QuickSight の解析能力により、数分で AWS のコスト詳細を確認することができました。

今すぐ利用可能
この機能は今すぐ使い始めることができます。

Jeff;

週刊AWS - 皆さんの支援を受けて復活!

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 に直接関連していること。
  • 所有権 – 寄稿内容の所有権は寄稿者が持つこと。
  • 有効性 – リンクはすべて一般公開されている内容であること (無料およびゲートしているコンテンツは問題なし)。
  • 適時性 – 寄稿した内容はすべて関連の日付に作成されたものであること。
  • 中立性 – 自分の意見を公開する場ではない点を忘れないこと。 事実とリンクのみを提供すること。

個人的にはクラウドビジネスに関する一般的なニュースは避けるようにしています。また、ベンチマークについて触れる場合は、まず同僚の許可を得ることにしています。では、次にスタイルについて簡単にご説明します。

  • 大方の場合、このブログのコンテンツのスタイルは「I wrote about POST_TITLE」や「We announced that TOPIC」といったものです。
  • 他の AWS ブログでは「The BLOG_NAME wrote about POST_TITLE」といったスタイルを使用しています。
  • そして個人からのコンテンツは「PERSON wrote about POST_TITLE」といった具合になります。
  • また、パートナーや ISV からのコンテンツは「The BLOG_NAME wrote about POST_TITLE」といったスタイルです。

従来の形式の他に新しいバリエーションがあっても構いませんが、その場合はクリーンで簡潔なものにしてください。私の過去の記事を参考にしても問題ありません。将来的には注目を集めやすいビジュアルデザインを取り組んでいく可能性もありますので、アイデア (もしくはコントリビューション) は大歓迎です。

項目
数年に渡り使用していきた項目は次の通りです。

  • デイリーサマリー – このブログのコンテンツ、AWS やその他のブログなど。
  • 新しい & 注目のオープンソース.
  • 新しい SlideShare プレゼンテーション.
  • 新しい YouTube の動画APN サクセスストーリーを含む。
  • AWS Marketplace に掲載された新製品など。
  • 新しいお客様事例.
  • 近日開催のイベント.
  • サポート募集.

RSS フィードがきっかけで注目するコンテンツもあります。私が GitHub リポジトリで使用する OPML ファイルを載せておきますので、スタートポイントとしてご活用ください。新しく注目に値するオープンソースの項目は AWS の GitHub 検索に由来します。検索結果をスクロールダウンして、気になる 10 件~15 件を選びます。興味深く関係性のあるリンクやディスカッションを探すために、個人的には /r/awsHacker News もチェックするようにしています。今後、グループや個人が 1 つの項目のメイン寄稿者になることも考えられます。もしそうなったらとても興味深いものになるでしょう。さらに、AWS との関係性が高いものであるならば、新しい項目を追加してもいいと思っています。

自動化
今年始めにプロセスを自動化しようとしたのですが、結果に納得することができませんでした。もし、試してみたい方がいればどうぞ。ただし、投稿内容の質を可能な限り維持していくため、自動化するとしても人間による判断力が必要だと考えています。

それではスタート!
このプロジェクトが始まってとてもワクワクしていると同時に、プルリクエストが届き始めるのを今から待ちわびています。ご提案や懸念するポイントがあれば、ブログのコメント欄でぜひお知らせください 。正直に申し上げて、私は Git ベースのコラボレーションの経験が浅いので、これは新しい学習経験になるだろうと思っています。他により優れたプロセスがあるとお考えでしたらお気軽にお知らせください、よろしくお願い致します。

Jeff;

 

※本内容はJeffが投稿する英語版の「AWS Week in Review」に対する翻訳記事です。

週刊AWS – 2016 年 8 月 22 日

これは、AWS Week in Review の最初のコミュニティ型エディションです。先週のブログ投稿 (AWS Week in Review – Coming Back With Your Help!) にお応えして、他の 9 名の寄稿者がこの投稿を現実のものとしてくれました。すばらしいスタートです。今週は 20 件にいくかどうか見てみましょう。

月曜日

8 月 22 日

火曜日

8 月 23 日

水曜日

8 月 24 日

木曜日

8 月 25 日

金曜日

8 月 26 日

日曜日

8 月 28 日

新しい & 注目のオープンソース

新しい SlideShare プレゼンテーション

近日開催のイベント

サポート募集

次週の投稿をお楽しみに。ぜひコミュニティ型の取り組みへの協力もご検討ください。

Jeff;

Amazon WorkSpaces の更新情報 – 時間単位の利用とルートボリュームの拡大

数か月前に公開したブログ I Love My Amazon WorkSpace では、私が Amazon WorkSpaces
をフルタイムで使用するようになった理由や、大ファンになった経緯についてご説明しました。

ブログを公開後、似たような感想を何人もの AWS ユーザーからお寄せいただきました。そこで今回は、今まで以上に経済的で柔軟性と実用性に優れた WorkSpaces を実現させたポイントについてご紹介します。

  • 時間単位で WorkSpaces を利用 – WorkSpace の料金を時間単位で支払えるようになりました。
  • ルートボリュームを拡大 – 新たにリリースした WorkSpaces のルートボリュームは 80 GB になりました。

次に各新機能の詳細についてご説明します。

時間単位で WorkSpaces を利用
WorkSpace へのアクセスはパートタイムで充分というユーザー (厳密に言えば組織) にとって、このオプションはメリットになるでしょう。すでにご提供していた月額オプションに加え、WorkSpace の使用量を時間単位で支払えるようになりました。これは AWS コストの節約にもつながります。パートタイム社員、出張の多い方、他のパートタイム社員と仕事を分割している方、複数の短期間プロジェクトに携わっている方などにとって、このオプションは最適です。企業研修プログラム、教育、リモート管理などにも大いに役立ちます。AlwasysOn と AutoStop という新しいモードが 2 つあります。

  • AlwaysOn – これは既存のモードです。WorkSpace が常に実行しているので瞬時にアクセスすることができます。お支払いは月額払いになります。
  • AutoStop – 新しいモードです。ログインすると WorkSpace が開始し、請求対象となる時間もその時点で開始します。指定した期間以上に切断状態が続くと、自動的に停止するようになっています。

AutoStop モードで WorkSpace を使用すると、接続を切断後、事前に決定した時間になると WorkSpace が自動的に停止します (1 時間から 48 時間)。WorkSpace の管理者は実行中の WorkSpace を強制的に停止させることもできます。次回の接続時に WorkSpace が再開します。開いていたドキュメントや実行していたプログラムの状態も変更されていません。停止していた WorkSpace を再開するには、約 90 秒ほど掛かります。WorkSpaces の管理者は、あなたの WorkSpace をスタートさせる時に、その実行モードを指定することができます。

WorkSpaces の構成

管理者は、その月の間にいつでも AutoStop タイムと実行モードを変更することができます。また、管理者は新しい UserConnected CloudWatch メトリックスを使用して、ひと月に WorkSpace を使用した合計時間を確認することができます。その後、経済的に適うようになった場合には実行モードを AutoStop から AlwaysOn に切り替えることが可能です。お支払い方法を時間制から月額に変更する場合はリクエストベースとなりますが、月額から時間制に変更する場合は翌月の月初めに行われます。本日より新しい Amazon WorkSpaces で時間制のオプションをご利用いただけます。WorkSpaces でカスタムイメージを使用している場合は、最新の Amazon WorkSpaces バンドルからカスタムイメージを更新してください。既存の WorkSpaces を対象にした時間制のオプションは今後追加する予定です。WorkSpaces の価格については WorkSpaces 料金表ページをご覧ください。

ルートボリュームの拡張
お客様から頻繁にリクエスト頂いていたため、新たにリリースした WorkSpaces ではルートボリュームのサイズを 80 GB に拡大しました。これにより、実行できるアプリケーション数も増え、追加費用なしに今まで以上の量のデータを保管できるようになりました。
WorkSpaces の管理者は、既存の WorkSpaces を再構築してルートボリュームの量を増やすことができます (詳しくは Rebuild a WorkSpace をご覧ください)。WorKSpace を再構築すると、ルートボリューム (C:) は WorkSpace の作成時に使用したバンドルの最新イメージに復元されます。また、最新の自動スナップショットからデータボリューム (D:) も復元します。

WorkSpaces のリソース
この機会をお借りして、その他の大切な WorkSpaces リソースもご紹介します。

  • スタートガイドWorkSpaces Getting Started ページには、詳しい手順を説明した WorkSpaces Implementation Guide や、その他の便利なドキュメントが含まれています。
  • 録画版オンラインセミナー – 先月下旬に私の同僚 Salman Paracha さんが Intro to Amazon WorkSpaces と題したオンラインセミナーを開催しました。このセミナーでは、世界中の様々な社員をサポートするため、そして組織のセキュリティを改善しながら、ユーザーが使い慣れた生産性の邪魔にならないデスクトップエクスペリエンスを提供する上で、WorkSpaces をいかに活用できるか説明しています。
  • ホワイトペーパーBest Practices for Deploying Amazon WorkSpaces というホワイトペーパーではネットワークの考慮事項、ユーザー認証のディレクトリサービス、セキュリティ、モニタリング、ロギングなどについて取り上げています。Desktop-as-a-Service のホワイトペーパーでは WorkSpaces の優れた運用コントロール、コスト削減、セキュリティのメリットなどについて説明しています。
  • 導入事例ルイジアナ州矯正省(Louisiana Department of Corrections)Endemol Shine グループの導入事例では、AWS のお客様がどのように WorkSpaces を利用しているかご覧ください。

今すぐ利用可能
上記の機能はすべて入手可能です。今すぐご利用いただけます。

Jeff