Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

ヒッグス粒子を発見した実験で自然界の調査に AWS を使用

同僚の Sanjay Padhi は AWS サイエンティフィックコンピューティングチームの一員です。Sanjay は、重要な科学的発見に役立つコンピューティングリソースを AWS がどのように提供したかに関するゲスト投稿を行いました。 – Jeff 質量の起源への洞察を提供する上で重要な役割を担うヒッグス粒子 (神の粒子と呼ばれることもある) は、2012 年に、スイスのジュネーブにある CERN の大型ハドロン衝突型加速器 (LHC) で、世界最大の実験装置である ATLAS および CMS により発見されました。この発見の基盤となる理論を提唱した研究者たちは、2013 年ノーベル物理学賞を受賞しています。 フランスとスイスの国境にまたがって地下深くに設置されている LHC は、世界最大 (全周 17 マイル) でこれまでにない高エネルギーの粒子加速器です。これにより、これまで探求してきたいかなる人間の発明よりも小さいスケールで自然界を探ることができます。 実験から生データへ 高エネルギー粒子の衝突により、質量はエネルギーに変換され、その後質量に再変換されて、新しい粒子が作り出されます。この粒子が CMS 検出器で観察されます。この検出器は長さ 69 フィート、幅 49 フィート、高さ 49 フィートで、フランスのセシー村近くにある地下 328 フィートのトンネルに設置されています。CMS からの生データは 1 秒あたり約 1 ペタバイトの割合で 25 ナノ秒毎に記録されます。 CERN Tier 0 データセンターで生データをオンラインおよびオフライン処理した後、そのデータセットは 48 […]

Read More

New – AWS CloudFormation の変更点

AWS CloudFormation を使用すると、AWS リソースのコレクション (「スタック」) を制御された予想可能な方法で作成、管理、および更新できます。CloudFormation を使用して、本番ワークロードを稼働するためのスタックの更新が 1 日に何十万回も実行されています。お客様は、初回のテンプレートを定義した後、要件が変わるとテンプレートを修正します。 通常「コードとしてのインフラストラクチャ」と呼ばれるこのモデルを使用すると、開発者、アーキテクト、および運用担当者の各チームが AWS リソースのプロビジョニングと構成を詳細に制御できるようになります。この制御と説明責任の詳細さは、CloudFormation を使用する際に最もはっきりとわかる利点の 1 つです。ただし、CloudFormation には、それほどはっきりとはわからないものの、同じくらい重要な利点がいくつかあります。 整合性 – CloudFormation チームは、AWS チームと連係して、リソースの作成、更新、および削除のセマンティクスについて、新しく追加されたリソースモデルでも整合性を保つようにしています。また、EBS ボリュームや RDS ボリュームの暗号化用の KMS キーなど、関連リソースの再試行、べき等性、および管理について説明できるようにしています。 安定性 – どのような配信システムでも、結果整合性に関連する問題は頻繁に発生し、必ず対処する必要があります。CloudFormation チームではこのような問題を十分認識しており、変更のプロパゲーションが必要な場合には、配信を実行する前に、自動的にそのプロパゲーションが完了するのを待つ仕組みになっています。多くの場合、CloudFormation チームはサービスチームと連係して、API と成功シグナルが CloudFormation で適切に使用できるよう調整されていることを確認します。 均一性 – CloudFormation では、スタックが更新される際に、インプレース更新とリソース置換のいずれかが選択されます。 この作業はすべて一定の時間がかかり、関連サービスが公開または更新される前にテストを完了できない場合もあります。 更新のサポートの向上 先述のように、AWS の多くのお客様が、本番スタックの更新を管理するのに CloudFormation を使用しています。お客様は、既存のテンプレートを編集 (または新しいテンプレートを作成) した後、CloudFormation の更新スタックオペレーションを実行して、変更を有効にします。 新しいテンプレートやパラメータ値に合わせてスタックが更新される際に CloudFormation が実行する変更の詳細について知りたい、というお問い合わせが、多くのお客様から寄せられています。変更のプレビューを行い、その変更が期待通りであることを確認してから、更新を実行するためです。 CloudFormation のこの重要なユースケースに対応するために、「変更セット」という概念を導入しました。変更セットを作成するための第 1 段階として、お客様は、更新対象のスタックに対する変更内容を送信します。CloudFormation では、更新対象のスタックが新しいテンプレートやパラメータ値と比較され、変更セットが作成されます。お客様は、この変更セットを確認してから、適用 […]

Read More

週間 AWS – 2016 年 3 月 28 日

先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 28 日 AWS Security Blog が、AWS CloudTrail を使用してフェデレーションユーザーを簡単に識別する方法を掲載しました。 BotMetric が、AWS セキュリティベストプラクティスの投稿シリーズに、データセキュリティと検出サービスについての 2 つの投稿を新たに追加掲載しました。 Evident が、AWS 用のプログラムによるセキュリティの自動化についての記事を掲載しました。 Cloud Academy が、AWS DevOps Pro 試験に合格するのに役立つヒントを掲載しました。 Cloudonaut が オブジェクトストアとしての Amazon S3 の活用法を掲載しました。 Gorillastack が、より多くのコンピューティングリソースを Amazon EC2 スポットインスタンスに移行する必要がある理由を掲載しました。 The Register が、Amazon WorkSpaces のリリース後のこの 2 年間を振り返る記事を掲載しました。 火曜日 3 月 29 日 AWS CloudFormation で変更セットが利用できるようになったことを発表しました。 Amazon […]

Read More

ElastiCache for Redis の更新 – エンジンのアップグレードとスケールアップ

Amazon ElastiCache は、クラウド内のインメモリデータベースのデプロイ、運用、スケールの実行を簡単にするサービスです。ご存知のとおり、ElastiCache では Memcached エンジンと Redis エンジンがサポートされています。 Redis 向けの強化 本日、Redis ベースの ElastiCache クラスターがより詳細に制御できるようになる、ElastiCache の更新をローンチしました。You can now scale up to a larger node type while 保存された情報を ElastiCache に保持したまま (ベストエフォートベース)、より大きなノードタイプにスケールアップできるようになりました。ElastiCache for Redis のエンジンバージョンのアップグレードはこれまでずっと可能でしたが、保存された情報を保ったままでこれを実行できるようになりました。これらの変更は、両方とも、即時適用またはクラスターのメンテナンス期間の適用が実行できます。 ElastiCache for Redis のスケールアップとエンジンアップグレードのために、見えないところでさまざまな戦略が活用されています。スケーリングは Redis レプリケーションをベースにしています。エンジンのアップグレードでは、マルチ AZ がオフになったときにまずフォアグラウンドのスナップショットが使用され (SAVE)、マルチ AZ がオンのときにレプリケーションに続いて DNS スイッチが実行されます。 大きなノードタイプにスケールアップするには、AWS マネジメントコンソールで [Cache Cluster] を選択し、[Modify] をクリックします。新しい [Node Type] を選択し、変更を即時適用するかどうかを決定してから、[Modify] をクリックします。 […]

Read More

Airbnb – AWS で宿泊業界の新しいスタイルをつくる

Airbnb は、わずか数人のすばらしい着想が業界全体を大きく変えることがあることを示す、典型的なストーリーです。2008 年にスタートして以来、これまでに 8000 万人の客が Airbnb を利用して 190 以上の国にある 200 万軒以上の家に宿泊しました。最近では、全世界からの旅行者のため、キューバに 4000 軒の家をオープンしました。同社はまた、早くから AWS を活用してきました。 ゲストによる以下の投稿の中では、Airbnb エンジニアリングマネージャーである Kevin Rice 氏が、スタートアップにおいて AWS がどれほど重要な役割を担ったか、そしてどのようにその重要な位置にとどまっているかを解説しています。 – Jeff PS – スタートアップが AWS を利用してビジネスを展開する方法の詳細についてもご覧ください。 初期 当社の創設者たちは、Airbnb を成功させるために、スピーディーかつリーンであることが必要だと認識していました。これには、インフラストラクチャに投じる時間とリソースを最小化することが不可欠です。当社のチームは、ベーシックなホスティングについての業務にではなく、ビジネスを離陸させることに集中することが必要でした。 幸いなことに、ちょうどそのとき、アマゾン ウェブ サービスにはコンピューティングとストレージにおいて非常に成熟したサービスが構築されていたため、当社のスタッフは他の人からのサポートや最小使用要件に気を使うことなく、サーバーを立ち上げることができました。同社のクラウドコンピューティング機能のほぼすべてを AWS に移行することが決定されました。スタート当初の小さな企業では、利用できるリソースを可能な限り活用する必要があります。当社の従業員たちは、ビジネスを成功させるために替えのきかないところに注意を集中したいと考えていました。 Airbnb では、Amazon EC2 や Amazon S3 といった AWS の基本サービスの多くをすばやく導入しました。当初の MySQL データベースは Amazon Relational Database Service (Amazon RDS) に移行されました。RDS […]

Read More

Amazon RDS for SQL Server – Windows認証のサポート

このブログの常連読者の方は私がAmazon Relational Database Service (RDS)の大ファンであることをご存じだと思います。マネージド型のデータベースサービスとして、リレーショナルデータベースのセットアップ、実行、そしてスケーリングといった日常業務の面倒を見てくれます。 2012年にはじめてSQL Serverのサポートをローンチしました。それからSSLサポート、メジャーバージョンアップグレード、透過的なデータ暗号化、そしてMulti-AZといった多くの機能を追加してきました。これらの機能はRDS for SQL Serverの適用範囲を広げてより多くのユースケースへの扉を開きました。 多くの組織ではアカウントのクレデンシャルとそれに関連するアクセス権をActive Directoryに保管しています。ディレクトリによりこの情報に対する単一で一貫性のあるソースを提供し集中管理を可能にします。AWS Directory Serviceを使用してAWSクラウド上でMicrosoft Active DirectoryのEnterprise Editionを実行することができますので、次のステップにすすむときです! Windows認証のサポートAWS Directory Service for Microsoft Active Directory (Enterprise Edition)に保存されたクレデンシャルを使用してAmazon RDS for SQL Serverに対するアプリケーションの認証ができるようになりました。同じディレクトリにすべてのクレデンシャルを保持することでそれぞれのコピーをさがして更新する必要がなくなるため時間と手間の節約になります。 SQL Serverを実行するデータベースインスタンスを新規に作成するときにこの機能を有効にしてActive Directoryを選択することができます。既存のデータベースに対して有効にすることもできます。こちらが新規にデータベースインスタンスを作成するときにディレクトリを選択するやり方です(新規にディレクトリを作成することもできます): より詳細は、Using Microsoft SQL Server Windows Authentication with a SQL Server DB Instanceを読んでください。 いますぐ利用可能この機能はUS East(北バージニア)、US West (オレゴン)、Europe(アイルランド)、Asia Pacific(シドニー)、Asia Pacific(東京)、そしてAsia Pacific(シンガポール)リージョンでいますぐ利用可能ですので今日からつかいはじめることができます。この機能に追加費用はありませんが、AWS Directory Service for […]

Read More

データの暗号化をシンプルにし、アプリケーションの可用性を向上する新しいAWS Encryption SDKの利用法

本日、AWSの暗号化チームは AWS Encryption SDKを発表します。この新しいSDKによって、開発者は、アプリケーションのセキュリティに影響を及ぼしうるエラーを最小化しながら容易に暗号化を実施できます。新しいSDKはAWSのお客様でなくてもご利用いただけますが、AWSのお客様にとってすぐに利用可能なサンプルが含まれています。   暗号化を行う際、開発者は次の2つの問題によく直面します: どのように正しく暗号鍵を生成し、利用するか 利用後、鍵をどのように保護するか 新しいAWS Encryption SDKによって提供されるライブラリは、ユーザーの開発環境で利用可能な暗号化プロバイダを利用し、低レベルの詳細な部分を透過的に実装することで1つ目の問題に対応します。また、どのように鍵を保護したいかを選択できる直感的なインターフェースを提供することで2つ目の問題への対応を手助けします。開発者は、暗号化の複雑性ではなく構築しようとしているアプリケーションコアにフォーカスすることが出来ます。この記事では、AWS Encryption SDKを利用してどのようにデータの暗号化プロセスを簡素化できるか、単一のリージョンあるいは鍵管理ソリューションに縛られない、アプリケーションの可用性を改善するのに役立つ方法でどのように鍵を保護できるかについてお伝えします。   エンベロープ暗号化と新しいSDK AWS Encryption SDKを利用する際に理解しておくべき重要なコンセプトは、エンベロープ暗号化(ハイブリッド暗号化としても知られています)です。アルゴリズムが違えば強度も異なり、単一のアルゴリズムで全てのユースケースにフィットするものは有りません。例えば、(RSAやAWS Key Mangement Service [KMS]などの)優れた鍵管理の特性を持つソリューションは、大容量のデータに対してはあまり有効ではありません。エンベロープ暗号化は、(AES-GCMのように)大容量データに適した単一用途のデータキーを使ってバルクデータを暗号化することでこの問題を解決します。エンベロープ暗号化ではその後、鍵管理に適したアルゴリズムや他のソリューションを使ってデータキーを暗号化します。 エンベロープ暗号化のもう一つの優位性は、複数の受信者で復号化できるようひとつのメッセージを暗号化できることです。全員で鍵を共有(これはたいていセキュアではありません)したり、全体のメッセージを複数回暗号化したり(これは現実的ではありません)するのではなく、データキーだけがそれぞれの受信者の鍵を使って暗号化されます。これによって重複した処理を顕著に削減でき、複数の鍵を利用した暗号化がより実用的になります。   エンベロープ暗号化の問題点は実装の複雑さです。全てのクライアントはデータフォーマットの生成および構文解析ができ、複数の鍵とアルゴリズムをハンドルでき、理想的には妥当な範囲で前方および後方互換性を保てる事が必須になります。   AWS Encryption SDKはどう役立つのか? AWS Encryption SDKは、セキュアなアルゴリズムの組み合わせ(将来的に拡張可能)をサポートし、マスターキーのタイプやアルゴリズムの制限が無い、慎重にデザインされレビューされたデータフォーマットを採用しています。AWS Encryption SDK自身は、KMS、および AWS CloudHSMやその他の PKCS #11デバイスを含むJava Cryptography Architecture (JCA/JCE)を直接サポートするpoduction-readyなリファレンスJava実装です。他言語でのSDKの実装については現在開発中です。 AWS Encryption SDKの一つの利点は、低レベルの暗号処理はSDKで取り扱われるため、データの移動にフォーカスすることができることです。次に、パワフルでセキュアなマルチリージョンソリューションを構築する簡単なコードを示します。   Example 1:高可用性のためにアプリケーションの機密データを複数リージョンのKMSマスターキーで暗号化する 高可用性アプリケーションのベストプラクティスの一つは、複数のアベイラビリティゾーンだけではなく複数のリージョンでデプロイすることです。KMSはリージョンをまたがってカスタマーマスターキー(CMK)を共有できないため、データがKMSで暗号化されている場合にはこのようなデプロイメントは困難です。エンベロープ暗号化では、異なるリージョンの複数のKMS CMKを使ってデータキーを暗号化することでこの制限に対するワークアラウンドを取ることができます。各リージョンで稼働するアプリケーションは暗号文の復号化を行うために、高速で信頼性の高いアクセスのためにローカルのKMSエンドポイントを利用することができます。 このドキュメントの全ての例において、 IAM roles for EC2を設定したAmazon EC2インスタンスが稼働していることを想定しています。IAM […]

Read More

AWS Marketplace 製品の料金オプション追加

AWS Marketplace は先進の ISV (独立ソフトウェアベンダー) に大いに活用されています。 ユーザーは、ハードウェアの調達やソフトウェアのインストールを行うことなく、数分のうちに製品を見つけ、購入し、使用を開始することができます。このようなスムースな配信方法によって、ISV は新たな顧客を得ると同時に、販売サイクルを短くすることもできています。ユーザーは既存の AWS アカウントを通じ、標準の AWS 請求サイクルにしたがって製品に対する支払いを行います。 AWS Marketplace へのオンボーディングプロセスの一部として、各 ISV はソフトウェアの料金を自由に決定できます。ISV は、割引のある月間利用料金や年間利用料金の設定も選択できます。従来は時間以外に基づいてライセンスされていたソフトウェアについても、ISV は AWS Marketplace に、自分で選択したディメンションでのライセンシングオプションに対応する複数のエントリを作成できます。 このモデルはさまざまなタイプのアプリケーションで効果を上げています。しかし、通常はまだ向上の余地があります。 他の料金オプション ソフトウェアのパッケージングと料金設定については、いっそうの柔軟性を求める声が ISV から届いていました。AWS ではそれにお応えします。複数エントリを作成せずにユーザー数モデルへの拡張を希望される場合もあれば、別のディメンションでの課金を希望される場合もあります。セキュリティ製品ベンダーは、スキャン対象のホスト数に応じた課金を希望するかもしれません。分析向けの製品のベンダーであれば、処理するデータ量に応じた価格設定を望むかもしれません。 これらの選択肢を実現させるため、ISV が自社製品にとって有効なディメンション (スキャン対象ホスト数、処理データ量など) に基づいて使用量を追跡し、レポートすることが可能になりました。これらの使用量について、単位あたりの価格を設定することも可能です (1 ホストあたり 0.50 USD、1 GB あたり 0.25 USD など)。このような使用量に対する課金は、ユーザーの AWS 請求に表示されることになります。 この変更によって、AWS Marketplace の製品ラインナップがいっそう広がることになるでしょう。 新しい料金オプションの実施 自社の AWS Marketplace 製品にこの新しいモデルの料金を使用することを希望する ISV は、アプリケーションにいくらかコードを追加する必要があります。適切なディメンションにより使用量を測定し、使用量をレポートする新しい AWS API 関数を呼び出します。このデータ […]

Read More

CloudWatch Metrics for Spot Fleets

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく(1台のインスタンスから何千台のインスタンスまで)費用対効果の高いキャパシティを複数プールからリソース提供します。この強力なEC2機能の詳細については、こちらのブログを参照下さい。【AWS発表】Amazon EC2 スポットフリート API – 一度のリクエストで数千台のスポットインスタンスを制御、【AWS発表】Spotフリート – コンソール、フリートスケーリング、CoudFormationに対応。 私は各スポットフリートを一つの集合体として考えます。フリートが起動すると、それぞれが独立したグループのEC2インスタンスとして起動します。スポット価格の変化や、フリートキャパシティの変更に伴いインスタンスの状態は変化しますが(可能な限り費用対効果を高めるよう変化)、フリート自体はその属性を保持します。 新しいスポットフリート メトリックス スポットフリートの管理、監視、拡張性をより簡単にするために、CloudWatchに新しいスポットフリート用メトリックが追加されました。メトリックスは、複数のディメンションからアクセスできます:スポットフリート毎、スポットフリートが構成されているアベイラビリティゾーン毎、フリート内のEC2インスタンスタイプ、アベイラビリティゾーン、インスタンスタイプ等。 下記メトリックスは各スポットフリート毎に取得されます。(これらメトリックスを取得するためには、EC2詳細モニタリングを有効にする必要があります) AvailableInstancePoolsCount BidsSubmittedForCapacity CPUUtilization DiskReadBytes DiskReadOps DiskWriteBytes DiskWriteOps EligibleInstancePoolCount FulfilledCapacity MaxPercentCapacityAllocation NetworkIn NetworkOut PendingCapacity StatusCheckFailed StatusCheckFailed_Instance StatusCheckFailed_System TargetCapacity TerminatingCapacity  メトリックのいくつかは、スポットフリートの入札プロセスのヒントとなるかもしれません。例えば、 AvailableInstancePoolsCount – スポットフリートのリクエストに含まれるインスタンス・プールの数を示します。 BidsSubmittedForCapacity – スポットフリート キャパシティの入札数を示します。 EligibleInstancePoolsCount – スポットインスタンスリクエストの対象となるインスタンスプールの数を示します。いずれか(1)スポット価格がオンデマンド価格より高い場合、または(2)入札価格がスポット価格よりも低い場合にはプールが不適用となります。 FulfilledCapacity – フリートキャパシティを満たす容量の合計を示します。 PercentCapacityAllocation – 特定ディメンションに割り当てられた容量の割合を示します。特定のインスタンスタイプに割り当てられた容量のパーセントを決定するために、インスタンスタイプと共に使用することができます。 PendingCapacity – ターゲットキャパシティと利用済みキャパシティの差異を示します。 TargetCapacity – スポットフリート内の現在要求されたターゲットキャパシティを示します。 TerminatingCapacity – スポットインスタンスの終了通知を受けたインスタンスのインスタンスキャパシティを示します。 これらのメトリックスは、スポットフリートの全体的なステータスとパフォーマンスを決定する手助けになります。メトリック名からも分かりますが、スポットフリート毎に消費されるディスク、CPU、およびネットワークリソースを確認することができます。また、スポットキャパシティ確保のために入札の前にどのような傾向があるかを確認することができます。それに加え、アベイラビリティゾーン、インスタンスタイプをまたいだ下記メトリックスも取得できます。 CPUUtilization DiskReadBytes […]

Read More

週間 AWS – 2016 年 3 月 21 日

先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 21 日 スポットフリート用の新しい CloudWatch メトリックスを発表しました。 AWS SDK for Java 用の再試行スロットリングを発表しました。 AWS マネジメントコンソールを介して Amazon Machine Learning を Amazon Redshift に接続することが簡単になったことを発表しました。 AWS Storage Gateway で最大 1 PB の仮想テープライブラリと、ゲートウェイあたり最大 512 TB の保管型ボリュームをサポートするようになったことを発表しました。 AWS Government, Education, & Nonprofits Blog が、AWS にすべてを移行した際に学んだ教訓についての記事を掲載しました。 AWS Mobile Development Blog が、CloudFormation を使用して AWS に Parse Server と MongoDB […]

Read More