Amazon Web Services ブログ

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] をクリックします。 […]

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 […]

このブログの常連読者の方は私が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 […]

本日、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 […]

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 関数を呼び出します。このデータ […]

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく（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 […]

先週 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 […]

週間 AWS – 2016 年 3 月 14 日 先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 14 日 AWS SDK for C++ の開発者プレビューが使用可能になったことを発表しました。 AWS クラウド 10 周年を祝いました。 Sqoop、HCatalog、Java 8 などを含む Amazon EMR 4.4.0 をスタートしました。 AWS コンピューティングブログで、欧州 (フランクフルト) リージョンにおける AWS Lambda および Amazon API Gateway の使用開始を発表しました。 Amazon Simple Email Service ブログで、Amazon SES がドメインからのカスタムメールをサポートするようになったことを発表しました。 AWS Java ブログに、Amazon SQS […]

Redshiftの新しいバージョン1.0.1040リリースについて、その新機能や修正一覧の説明とメンテナンスの予告が公開されています。 Release: Amazon Redshift on 2016-03-17 Announcement: Amazon Redshift improvements and maintenance (Mar 17 – Mar 31) このリリースには以下の新機能が含まれています。 ユーザが定義したしきい値よりも大きい比率でソート済の表は、VACUUMでソートをスキップするように COPYで条件にそったデータを挿入した場合、ソート済の領域としてマージされるように 接続ログに、SSLのバージョンとSSLサイファーが記録されるように 1.はVACUUMコマンドの機能改善です。VACUUMは不要領域の削除とソートという2つの機能を持っているのですが、すでに大半の領域がソート済の場合はソート処理自体をスキップすることでVACUUMに掛かる時間を短縮します。 デフォルトではその閾値は95%に設定されていますが、これはユーザが指定することが可能です。VACUUMコマンドが拡張されTO sort_threshold PERCENTという形で指定できます。この数値を100にした場合は（今までと同様）常にソートが実行されるようになりますし、逆に0にするとソートが行われなくなります。この新しいオプションはREINDEXやDELETE ONLY等とも併用可能です。 参考）VACUUMコマンド　※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。 2. ですが、Redshiftの中では表のデータは「ソート済領域」と「非ソート済領域」に分けて管理されています。VACUUMを使ってソートされたデータはソート済領域に保存され、追加データは非ソート領域に保存されます。 今回の機能拡張では、条件を満たした場合にCOPYで追加したデータがソート済領域に追加されるようになります。その条件はマニュアルの以下のページに記載されています。 Loading Your Data in Sort Key Order　※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。  条件は以下の通りで、これらを全て満たしている必要があります。 表がコンパウンドソートキー（Interleaved Sort Keyではなく）を使っていて、かつソートキー列が1つのみ ソートキーの列がNOT NULL 表が100%ソート済か、もしくは空（から） 新しく追加されるソートキー列の値が既存データよりソート順で大きい値を持つ これは、列に常に大きい値が挿入されるようなケース、つまり時刻がソートキーになっていて、そこに追加で新しいデータを追加し続けるような表構造（時系列でデータを入れ続ける）の場合に役に立ちます。 3.は記述のままですね。STL_ CONNECTION_LOGにsslversionとsslcipherという列が追加されています。もしこのSTL表を定期的に別表やファイルにエクスポートしている場合は、クラスターバージョンが上がった途端に列が増えるのでご注意ください。 この他に、INリスト指定時にスキャン範囲を限定することで速度を向上させる機能や、クラスターリサイズ時の転送スループット向上（リサイズに掛かる時間の短縮）、Window関数利用時にORDER BY句が必須ではなくなるといった機能向上、およびバグの修正が行われています。 この新しいバージョンはこれから約2週間にかけて各リージョンにデプロイされます。適用されるとクラスターのバージョンが1.0.1040になっているはずです。 なお、すでにオレゴンリージョン(US-WEST-2)にはデプロイされていますので、新規にオレゴンでRedshiftクラスターを立ち上げると1.0.1040で起動できます。すぐに新機能を確認したい方はオレゴンで試してみてください。 下佐粉　昭（@simosako）

AWS IoT のルールでデバイスが生成したデータを直接、 Amazon Elasticsearch ドメインに渡すことができるようになりました。これによってデータを分析したり、データに対してフルテキストやパラメータによる検索を実行したり、 Kibana で可視化したりすることができます。この連携によって、デバイスの特定のエラーコードをフルテキスト検索したり、デバイスのパフォーマンスをリアルタイムに近い形で視覚化するような、ユースケースをサポートします。 加えて、AWS IoT のルールによって、デバイスが生成したデータを Amazon CloudWatch に発行することができるようになりました。これによって、デバイスのメトリックスをグラフ化して見たり、アラートをセットすることができます。 これらの新しいルールをどのように利用するかについての、より詳しい情報については、AWS IoT デベロッパー ドキュメントを参照してください。または、コンソールにサインインして、ルールを試すことができます。   日本語への翻訳は SA福井が担当しました。原文はこちらです： https://aws.amazon.com/jp/about-aws/whats-new/2016/03/aws-iot-integrates-with-elasticsearch-service-and-cloudwatch/