Amazon Web Services ブログ

みなさん、こんにちは。 アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。 AWS Summit Tokyo 2018 の基調講演にてアナウンスいたしました、Amazon Elastic File System (EFS)が東京リージョンで今日一般提供が開始されました。 Amazon EFSは複数のEC2からマウント可能なファイルストレージサービスです。従来ご利用いただいていたブロックストレージであるAmazon Elastic Block Store (EBS)との使い分けの考慮が大事なサービスとなりますので、その特徴とご利用における検討事項を纏めます。 Amazon EFS の特徴 Amazon EFSはシンプルで、スケーラブル、伸縮自在なファイルストレージを、AWS クラウドサービスとオンプレミスの両方でご利用いただくことが可能です。 シンプル – ファイルシステムを迅速かつ容易に作成および構成できるシンプルなウェブサービスインターフェイスを備え、ファイルストレージインフラストラクチャを管理するため、複雑なデプロイ、パッチ適用、複雑なファイルシステムデプロイメントを維持する必要はありません。また課金体系もシンプルであり、保存されているデータ容量にたいしてのみ課金されます。東京リージョンでの価格は0.36USD / GBとなります。 スケーラブル – ファイルシステムの拡大に合わせて、スループットおよび IOPS が自動でスケールされます。こちらにパフォーマンスについてはまとまっています。 伸縮自在 – ファイルの追加や削除に合わせてファイルシステムのストレージ容量を直ちに自動で拡張または縮小でき、これによりスループット及びIOPSが変動します。 高可用性および高耐久性 – ファイルシステムの各オブジェクト (ディレクトリ、ファイル、リンクなど) は、複数のアベイラビリティーゾーンに冗長的に保存されるため、高いレベルの可用性と耐久性を確保できます。 オンプレミス環境からの利用 – AWS Direct Connect で Amazon VPC に接続し、オンプレミスのデータセンターサーバーにファイルシステムをマウントすることが可能です ご利用上の留意点 EFS はNFS v4 プロトコルをサポートしています。NFS […]

AWS re:Invent に参加した Discover Financial Services (DFS) のチームメンバーが、Robocar Rally はインパクトがきわめて強いイベントだったと語りました。Discover のコアチームのメンバー 6 名はこのハッカソンに参加し、機械学習 (ML) および AWS に関する深層学習を使用したハンズオン体験をしました。彼らにとってその楽しい時間は、永く記憶に残るものとなりました!Discover の Cloud Center of Excellence (CCoE) はのちに、ある 1 つのアイデアを提案しました。それは、「Discover 本社のオンサイトで同じイベントを再現してみよう」というものです。Discover CCoE にはそのリーダーシップおよびデータサイエンスチームをもって機械学習実験の現状にインパクトを与えるために、AWS AI/ML サービスに対する認識を高めようという目標がありました。そのイベントが実現するのに、2 か月半かかっていません。 チーム編成 Discover はイベント開催中にチームあたり 6 名からなる 6 チームを編成し、ハッカソンに参加して、1 対 1 で直接競わせました。Discover は多数の事業領域にわたる多様な縮図を体現しています。これが開発者からセキュリティ専門家にいたる混合環境を構築しており、そこには機械学習の関係者も含まれます。チーム規模およびチーム数は、カスタマーの関心と過去の Robocar Rally のイベントから継承されてきた知見をすり合わせた結果としてそうなりました。 Robocar の役割 AWS はこのイベント運営および各チームメンバーに対する戦略的な役割分担を目指して、規範的なアプローチを使用しました。 ドライバー: モデルのトレーニング中はクリーンデータの収集を確保しながら、車両を管理し、イベント開催中は Robocar を管理します。 Robo […]

Lambda@Edge をより活用いただくために Lambda＠Edge ベストプラクティスシリーズと題したブログを連載します。この中ではいくつかのユースケースを用いて Lambda@Edge をどのように利用すればよいか、CI/CD パイプラインにどのように組み込むべきか、ビジネスニーズに応える形で組み込まれていることを担保するためにはどのように考えればよいか等について取り上げます。 記念すべき初回は Lambda@Edge のデザインベストプラクティスについて取り上げます。いくつか一般的なユースケースをもとに関数をどのタイミングで実行するのが良いのか、それはどのような観点で選択されるべきかということについてパフォーマンス及びコスト最適化の観点から推奨構成について説明していきたいと思います。

MySQL と互換性がある Amazon Aurora はデータベースワークロード統合を検討中のお客様から好評をいただいています。Aurora MySQL は、ハイエンドな商用データベースの速さや信頼性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。また Aurora MySQL は、標準の MySQL Community Edition に比べ最大 5 倍のスループットを実現します。 今回のブログ記事では、大規模な統合データベースワークロードのために行う Amazon Aurora の最適化に役立つガイダンスをいくつかお伝えします。また、「統合の費用はどれくらいかかりますか?」や「データセットはどのくらいの大きさにできますか?」など、よくある質問にお答えします。 上記の質問はシンプルですが、必ずしも回答がシンプルになるわけではありません。回答は、お使いのデータセットやワークロードのパターンによって大きく異なります。 データベース統合の定義 統合のユースケースに関しては、以下の要素に的を絞り、それからコンテキストに応じた Aurora MySQL の操作方法について詳細を説明します。 テーブルのサイズ。統合により、一般的にテーブルは大きくなります。アドテック、IoT、消費者向けアプリケーション分野の場合、通常は大きな同種アプリケーションのデータベースをそれぞれにデータのサブセットが含まれる大量のシャードに分割します。Aurora ではシャーディングを完全になくすことはできないかもしれませんが、より少数のシャードに統合して操作上のオーバーヘッドを減らすことができます。 テーブルの数。テーブル数の増加も、統合の結果見られることです。この結果は、各テナントが通常、独自のデータベースまたはテーブルセットを有する場合にテナントの分離が必要な SaaS アプリケーションで一般的なものです。このタイプの複数のテナントは数が少なくより大きな Aurora クラスターにまとめられ、テナントあたりの操作コストを削減します。 データベースの使用率。さらに多数の同時接続を行うなど、統合データベースワークロードの使用率が多くのメトリクスで増加します。 実際には、同じプロジェクト内の複数の要素で使用率が増加することになります。以下のガイドラインは、各要素でワークロードを最適化するのに役立つはずです。 「大きい」とは具体的にどのくらいのサイズですか? Amazon Aurora には最大容量に制限があります。私たちの最も重要な成果は、Aurora クラスターで 64 TB という最大の保存容量です。最大容量により、Aurora クラスターに物理的に保存できるデータ量の上限が決められます。また、個々のテーブルの大きさについて上限が決められます。 加えて、MySQL と互換性があるデータベースエンジンとして、Aurora MySQL は MySQL と InnoDB ストレージエンジンから多くの特徴を受け継いでいます。これらの特徴には効果的な統合に影響を与えるものがあります。 大きなテーブルサイズを最適化する方法 Amazon Aurora […]

この記事では、Amazon Relational Database Service (Amazon RDS) for PostgreSQL 中央データベースを、Amazon Kinesis Data Streams にその変更をストリーミングすることで、他のシステムと統合する方法について説明します。以前の記事、「Amazon Kinesis を使用したデータベースの変更をストリーミングする」では、変更を Kinesis へストリーミングすることによって、MySQL データベース用の中央 RDS を他のシステムに統合する方法についてお話ししました。この記事では、さらに進んで、AWS Lambda 関数を使用して Amazon RDS for PostgreSQL の変更をキャプチャし、その変更を Kinesis Data Streams にストリーミングする方法を説明します。 次の図は、分散システムにおける一般的なアーキテクチャ設計を表しています。これには、信頼できる唯一の情報源と呼ばれる中央ストレージと、この中央ストレージを使用するいくつかの派生「サテライト」システムが含まれます。 この設計アーキテクチャーを用いて、データの整合性を維持するためにこのシステムのトランザクション機能を活用しながら、リレーショナルデータベースを中央データストアとして使用することができます。このコンテクストにおいての派生システムとは、全文検索システムであり、この信頼できる唯一の情報源の変更を観察し、それらの変更を変換かつフィルタリングし、最終的にその内部インデックスを更新するものです。もう 1 つの例は、OLAP クエリにより適したカラムナストレージです。一般に、中央リレーショナルシステムの個々の行が変更された時にアクションを実行する必要があるシステムはどれも、派生データストアにするのに適しているとい言えます。 この種のアーキテクチャの単純な実装では、変更された行を検索するために定期的にクエリを発行する派生システムがあります。これは基本的に SELECT ベースのクエリ (バッチ処理システムとも呼ばれます) で中央データベースをポーリングします。一方で、このアーキテクチャにより適した実装は、非同期の更新ストリームを使用するアーキテクチャです。 データベースには通常、行のすべての変更が格納されるトランザクションログがあります。ですので、この変更のストリームが外部のオブザーバシステムに公開されている場合、このシステムはこれらのストリームに接続し、行の変更を処理およびフィルタリングできる可能性があります。 この記事では、PostgreSQL を中央データベースとして、また Kinesis Data Stream をメッセージバスとして使用して、この基本的な実装を紹介します。 通常、PostgreSQL Write-Ahead Logging (WAL) ファイルは、マスター上のすべての変更を読み込んだ後、ローカルに適用するリードレプリカに公開されます。リードレプリカからデータを読み取る代わりに、wal2json 出力プラグインを用いた論理デコードを使用して、WAL の内容を直接デコードします。プラグインはこの GitHub […]

MySQL は世界で最も普及しているオープンソースデータベースです。それにも関わらず、多くの利用者が一様にバックアップ、高可用性の確保にかかる膨大な手間に苦心していたり、また MySQL のスケーリングが複雑である、時間がかかる、あるいはその両方であると感じています。 お客様がそうした既存の MySQL 環境から Amazon RDS for MySQL へ移行する最大の理由の 1 つはそこにあります。Amazon RDS はポイントインタイムリカバリや高可用性などのオプションを複雑な設定など一切なしですぐに使用できる機能を提供します。RDS for MySQL はさらに、ソースあたり 5 つのリードレプリカに対応しています。このように、バイナリログ (binlog) レプリケーションを手動で設定したり、保守したりする必要なく、簡単にワークロードをスケールできます。 MySQL にハイエンドコマーシャルデータベースのパフォーマンスおよび可用性との互換性を期待するのであれば、MySQL データベースを Amazon Aurora に移行することでそれを実現できます。MySQL との互換性を持つ Amazon Aurora を使用することで、fast database clones および autoscaling replicas などの機能を活用できます。また、AWS Lambda および Amazon CloudWatch Logs といった他の AWS サービスとのネイティブ統合も可能になります。これらの機能に加えて、Amazon Aurora はまた、3 つのアベイラビリティーゾーンをまたぐデータのレプリケーションにより、優れた耐久性を実現します。また、最大で 15 個の Aurora レプリカにスケール可能で、すべてが通常では 20 […]

SAP HANA on AWSクイックスタートのメジャーアップデートをリリースできたことを嬉しく思います。今回のリリースでは、高可用性のためのシングルノード構成のマルチAZ配置をサポートしました。 マルチAZオプションでは、Amazon Web Services (AWS)上のSAP HANA環境として2つのアベイラビリティゾーン (AZ)を使います。プライマリとセカンダリの2つのSAP HANAサーバーを個別のプライベートサブネットに展開し、高可用構成を設定します。新規の仮想プライベートクラウド (VPC)を作成するか、既存のインフラストラクチャにSAP HANAサーバーを展開するかを選択できます。展開には約35分かかります。

Goodreads では現在、モノリシックな Rails アプリケーションをマイクロサービスに分解している途中です。これらのサービスの大半は、Amazon DynamoDB をプライマリデータストアとして使用することに決めました。DynamoDB はストレージとスループットのさまざまなニーズに対応して、一貫した、数ミリ秒のパフォーマンスを提供できるため気に入っています。 しかし DynamoDB は高スループットの読み書きワークロードで優れていますが、1 回限りの、アドホックなクエリやデータウェアハウスワークロードをサポートするようには最適化されていません。しかし、AWS Data Pipeline、Amazon S3、AWS Glue、Amazon Athena を組み合わせることで、DynamoDB から S3 にデータセットをエクスポートし、Athena を使用してデータセットで SQL クエリを実行できます。

先日 (2018/7/3) 開催しました AWS Black Belt Online Seminar 「Amazon Neptune」 の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20180703 AWS Black Belt Online Seminar Amazon Neptune PDF Q. DynamoDBを利用するのはLambdaなどのMicroserviceとの親和性が高いためです。ネプチューンとLambdaの関係はどうですか ? A. HTTP RESTが使えるのでRDBMSのDB接続と比較して親和性は高いです。 Q. 暗号化を有効にした際は、性能が落ちるのでしょうか。落ちる場合は、どの程度落ちるかの指標等はありますか A. 格納データの暗号化について、特筆すべきオーバーヘッドはありません。 Q. オンデマンドインスタンス料金はRI適用は可能でしょうか。 A. いいえ、現在RIは使用できません。 以上です。 直近で以下の無料オンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております！ AWS Black Belt Online Seminar AWSで実現するウェブサイトホスティング 2018 年 7 月 10 日 | 12:00 – 13:00 | IT 知識レベル:★★☆☆☆ […]

みなさんこんにちわ。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。   2017年12月にご案内したAmazon Linux 2 の正式版が一般公開開始されましたのでお知らせいたします。また日本語版FAQも併せて更新されています。Amazon Linux 2 がAmazon Linux と異なる主な特徴は以下です。 Long Term Support (LTS) の提供 コアに含まれるパッケージに対し、セキュリティ更新とバグ修正を5年間提供 ユーザー空間のアプリケーションバイナリインターフェイス (ABI) とアプリケーションプログラミングインターフェイス (API) の互換性を 5 年間維持 LTSの提供は2017 年 12 月 13 日と 2018 年 4 月 9 日にリリースされたLTS Candidate 版には適用されないのでご注意ください。 オンプレミス環境のサポート VMWare、KVM、VirtualBox (Oracle VM)、Microsoft Hyper-V　の4つの仮想プラットフォームをサポートしており、最小で512MBのメモリ環境で動作します。それぞれ以下からイメージをダウンロードできます。 VMWare KVM Oracle VirtualBox Microsoft Hyper-V その他、詳しい情報はこちらにまとまっていますので是非ご確認ください。従来のAmazon Linux […]