Amazon Web Services ブログ

新発表 – 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

AWS OpsWorksが9つのリージョンエンドポイントとアジアパシフィック(ソウル)リージョンをサポート

AWS OpsWorksはアジアパシフィック(ソウル)リージョンで利用可能になりました。さらに、次の新しいリージョンエンドポイント:EU(フランクフルト)、EU(アイルランド)、US West(北カリフォルニア)、南アメリカ(サンパウロ)、アジアパシフィック(ソウル)、アジアパシフィック(シンガポール)、そしてアジアパシフィック(東京)で利用可能になりました。

以前は、これらのリージョンにあるOpsWorksのリソースにアクセスするためには US East(バージニア北部)のエンドポイントを使う必要がありました。今回の発表により、スタックと同じリージョンにあるエンドポイントを利用可能になりました。これによりAPIの遅延を減らし、レスポンスタイムの改善、そしてクロスリージョンに依存した障害のインパクトを限定することが可能です。

リージョンエンドポイントのリストの詳細はAWSリージョンとエンドポイントをご覧ください。
OpsWorksの詳細:
製品ページ
ドキュメント

舟崎が翻訳しました。原文はこちらです。

新発表 – AWS Key Management ServiceでのBring Your Own Keys機能

AWS Key Management Service (KMS) は暗号鍵のシームレスな中央集中管理を提供します。私達のお客様は、鍵管理インフラストラクチャ(KMI)に関する、可用性、スケーラビリティ、物理的なセキュリティ、ハードウェアメンテナンスを自動的にハンドルするこのフルマネージドなサービスをとても気に入っています。また、KMSは、作成、ローテーション、ライフサイクル管理機能を持つ一つのダッシュボードで鍵管理を集中化します。初期費用無し、カスタマーマスターキー(CMK)1つ当たり月額$1の利用価格をベースとして、KMSは、S3, EBS, RDS, Redshift, およびその他のKMSとインテグレートされたAWSサービス内に保管されたデータを容易に暗号化することが出来ます。

多くのAWSのお客様は、鍵を作成して管理するのにKMSを利用しています。しかしながら、KMSが提供するその他の機能を活用しながら、鍵に対するローカルコントロールを維持したいというお客様がいらっしゃいます。お客様は私たちに、世代や鍵の保管場所に関するローカルコントロールは、よりセンシティブなワークロードをクラウドで稼働させるためのセキュリティとコンプライアンス要求を満たすのに役立つと仰っています。

Bring Your Own Keys 
このような重要なユースケースをサポートするために、本日、KMSにユーザー独自の鍵を持ち込むことが可能になったことを発表できることを嬉しく思います。この機能により、極めてセンシティブなワークロードが保護でき、AWSの外に鍵のセキュアなコピーを保持することが可能になります。この新しい機能により、RSA PKCS #1標準をサポートする全ての鍵管理およびHSM(Hardware Security Module)ソリューションからの鍵のインポートが可能になり、その鍵をAWSサービスおよびアプリケーションから利用することが可能になります。また、KMSは詳細な監査情報を提供するためにAWS CloudTrailと協調して動きます。全てをまとめると、高可用性を提供するためにAWSを利用すれば、鍵のライフサイクルと耐久性に強大なコントロールを得ることができます。今日のほとんどの鍵管理ソリューションはHSMをバックエンドに使っていますが、全てのHSMが鍵管理ソリューションを提供するわけでは有りません。

インポートプロセスは、AWSマネージメントコンソールを使う,  AWS CLIを使う,  あるいは KMS APIをコールすることによって開始できます。オープンな環境に秘密鍵を転送させないために、インポートプロセスでは、アカウントにユニークな、KMSによって提供される公開鍵を使って、事前にユーザーのKMIの鍵をラップすることが求められます。鍵をラップするために、PKCS #1 スキームを利用することができます。

私は、Importing Key Material in AWS Key Management Serviceの指示に従って、KMSコンソールでCreate keyをクリックすることから始めます:


エイリアスと説明を入力し、外部(External)を選択し、“I understand…”チェックボックスにチェックを付けました:


それから、鍵管理のためのKMS APIを許可するIAMユーザーのセットを選びます。(このステップは、次に行うようにKMSおよび外部キーの両方に適用されます。):


次に、鍵を使ってデータの暗号化/復号化ができるIAMユーザーのセットを選択します:


キーポリシーを確認し、ラッピングキーとインポートトークンをダウンロードしました。ラッピングキーは、私がKMSにインポートして使おうとしている256bitの秘密鍵を暗号化するのに利用する2048bitのRSA公開鍵です。インポートトークンは、私の鍵をKMSに正しくインポートさせるためのメタデータを含んでいます。


ZIPファイルを展開し、ラッピングキーを私のEC2インスタンス上のディレクトリ上に配置しました。それから、opensslコマンドを2度使いました:一度目は秘密鍵を生成するためで、2度目はその秘密鍵をラッピングキーでラップするためです。インポートする256bit鍵を生成するためにopensslを便利な方法で利用している事に注目してください。本番データ用としては、鍵の生成と保管にもっとセキュアな方法(商用の鍵管理やHSMソリューションが望ましい)を利用すべきです。

$ openssl rand -out plain_text_aes_key.bin 32
$ openssl rsautl -encrypt -in plain_text_aes_key.bin -oaep \
-inkey wrappingKey_fcb572d3-6680-449c-91ab-ac3a5c07dc09_0804104355 \
-pubin -keyform DER -out enc.aes.key

最後に、“I am ready to upload…”をチェックしてNextをクリックし、鍵の有効期限と共に鍵マテリアルを指定して、全ての情報が集まります。有効期限を過ぎた後はAWSから利用できなくなるので、要件がはっきりするまで有効期限無しのオプションを選択したいと考えるかもしれません。いつでも同じ鍵を再インポートして、有効期限を後からリセットすることができます。


Finishをクリックして、鍵が有効化され利用できるようになりました:

これが私がやらなければいけなかったことの全てです!

私は鍵の有効期限を設定したので、KMSは自動的に鍵の有効期限までの残り時間を追跡するためのCloudWatchメトリックを生成しました。このメトリックに対して、有効期限に近づいた時に鍵を再インポートするためのリマインダーとしてCloudWatchアラームを作成することが可能です。鍵が有効期限切れになったら、CloudWatchイベントが生成されます。これを利用してプログラマティックにアクションを取る事もできます。

Available Now

この新しい機能は、AWS GovCloud (US)および、中国(Beijing)を除く全てのコマーシャルAWSリ―ジョンでご利用可能です。本日から使いはじめることが出来ます。

Jeff;(翻訳はSA布目が担当しました。原文はこちら)

AWS Snowball アップデート – ジョブ管理API & S3 アダプタ

AWSは昨年秋のre:inventから、AWS Import/Export Snowballを導入しました。
Snowballアプライアンスは1度で、あるいは繰り返し大量のデータをAWSへ持ち込み/持ち出ししたいお客様のためにデザインされています。(詳細はAWS Import/Export Snowball – Amazon所有のストレージアプライアンスを利用して1週間あたり1ペタバイトのデータ転送を実現をご参照下さい。)
本日、Snowballに対する2つの重要な追加機能を発表します。以下がその内容です:

  • Snowball ジョブ管理API – Snowballジョブを作成し、管理するアプリケーション構築が可能な新しいSnowball API
  • S3 アダプタ – SnowballアプライアンスがまるでS3エンドポイントであるかのようにアクセスするための新しいSnowball S3アダプタ

もう少し詳細を見てみましょう。

Snowballジョブ管理API
従来Snowballのモデルは、インタラクティブでコンソールから操作するものでした。(基本的に、”Snowballを私に送ってください”という)ジョブを作成し、その後その進捗をモニタリングし、出荷、配送状況、着荷およびAWSへの返却を視覚的に追跡できました。これは、素晴らしいワンオフジョブでしたが、Snowballを既存のバックアップやデータ転送モデルと統合したいと考えるお客様のニーズに合うものではありませんでした。これらのお客様や ストレージパートナー様から頂いたリクエストに基づいて、本日、Snowballジョブ管理APIを導入しました。

Snowball ジョブ管理 APIによって、お客様とパートナー様は、Snowballを自身のデータ管理ソリューションの一部として統合することが可能になります。以下が主要なファンクションです:

  • CreateJob – インポート/エクスポートのジョブを作成し、アプライアンスの出荷を開始します
  • ListJobs – ジョブのリストとステータスを取得します
  • DescribeJob – 特定のジョブについての情報を取得します

より詳細については API リファレンス を参照してください!

この新しいAPIを利用したクリエイティブでイノベーティブなアプリケーションが出てくるのを楽しみにしています!思いついたことがあれば、コメントに残してください!

 

S3 アダプタ
新しいSnowball S3 アダプタによって、まるでAmazon S3 エンドポイントがオンプレミスで稼働しているかのようにSnowballにアクセスすることが出来ます。これによって、Snowballへのデータの出し入れに今お使いのS3セントリックなツールをご利用いただけます。アダプタは、複数のLinuxディストリビューション及びWindowsリリースで利用可能であり、簡単にインストールできます:

  1. Snowball Toolsページから適切なファイルをダウンロードしてローカルディレクトリに展開する
  2. アダプタの構成が適切かどうかを確認する(アダプタはデフォルトで8080ポートをリッスンします)
  3. Snowballをネットワークに接続しそのIPアドレスをビルトインディスプレイから取得する
  4. コンソールを開いてアンロックコードとジョブマニフェストを取得する
  5. IPアドレス、アンロックコード、マニフェストファイルを指定してアダプタを起動する

アダプタが起動すれば、ローカルエンドポイント(オンプレミスホストのIPアドレスとリスナーポート)を使うよう構成するだけでご自身のS3セントリックツールが利用できます . 例えば、こちらが s3 ls コマンドをオンプレミスホストで実行する方法です:

$ aws s3 ls --endpoint http://localhost:8080

Snowballにファイルをコピーした後に、期待したファイル数がコピーされたかどうかを簡単に検証することが出来ます。:

$ snowball validate

アダプタの最初のリリースは、バケットおよびサービスに対するGET、バケットとオブジェクトに対するHEAD、オブジェクトに対するPUTおよびDELETE、そしてすべてのマルチパートアップロードオペレーションを含む、S3 APIのサブセットをサポートします。ご自身のコードやサードパーティのツールを利用してアダプタにアクセスしようと思われている方は、テストを実施することをお勧め致します。

より詳細については、 Snowball Transfer Adapterを参照ください。

今利用できます!
これらの新しい機能は、今ご利用可能ですので本日から使いはじめることができます!

Jeff;(翻訳はSA布目が担当しました。原文はこちら)