Amazon Web Services ブログ

この記事を書いている時点で、re:Invent 2018 開催まであと 138 日になりました。イベントチームの同僚たちは、全てのお客様がラスベガスで最高の経験ができるよう、総力を尽くしています。同僚とのミーティング後、この投稿を書くことにしたのは、お客様が会場にあるものをもっと理解し、何を期待できるかが分かり、お客様の方で計画と準備を進めることができるのでは、と思ったからです。 規模を考える このイベントの規模に関する課題について、考えることから始めました。2017 年のイベントには、約 43,000 人 (AWS のお客様、パートナー、報道関係者、業界アナリスト、AWS 従業員を含めて) が参加しました。クラウドアーキテクチャで使われるスケーリングの原則やベストプラクティスを数多く、このような大規模で複雑なイベントで重要となる物理的、ロジスティック的、そしてコミュニケーション上で生じる課題に対して適用しています。 場所の移動をもっと楽にしたいと同時に、そうする必要性自体を減らそうと考えています。私たちチームが現在行っていることは、次のようなものです。 キャンパスシャトル – 2017 年には、何百ものバスが数ある re:Invent の会場間を往復しました。その結果、運行系統に大幅な遅延が発生して、満足いくものではありませんでした。2018 年は、車両の数を増やし、直通だったバスを各停車場を巡る各停のものにし、さらにそれぞれの会場にはピックアップおよびドロップオフポイントを作りました。これで、行きたい場所へひとっ飛びです。 ライドシェアリング – Lyft と Uber (両社とも AWS をご利用くださっています) の協力の下、他にも交通手段をご用意しています (現在準備中ですが、アプリをダウンロードできます)。ラスベガスモノレールとタクシー会社にも協力いただいて、さらにはテレポーテーションサービスも現在準備していますが、開催に間に合うかどうかは未定です。 セッションアクセス – 複数の re:Invent 会場にまたがるしっかりとした予備スペースシステムも設置中で、人気の高いセッションを複数の会場で繰り返し行うことが可能となっています。 モバイルアプリの改善 – re:Invent のモバイルアプリはさらに使い勝手がよくなり、位置認識も行えるようになりました。空席のあるセッションを見つけたり、近くで何が行われているか、さらにはシャトルや他の交通手段を知らせてくれます。 みんなのためのもの re:Invent を参加者の皆様全員を暖かく歓迎する場所にし、斬新かつ開放的なビジネスやソーシャルのためのイベントにしたいと考えています。会場でのプランを少しお見せしましょう。 4 キロと 8 キロのチャリティファンラン – ファンランで一日を始めましょう。このイベントは Girls Who Code をサポートしています。 We […]

ゲノムシーケンスのコストは急速に低下し、公的に利用可能なゲノムデータ量はここ数年間で上昇しています。新しいコホートおよび研究では、100,000を超える個人で構成される膨大なデータセットが生成されています。同時に、これらのデータセットは、各コホート向けの様々なデータの膨大な量を生成する人口の中で遺伝的変異を抽出するよう処理されています。 ビッグデータのこの時代において、Apache Spark のようなツールはラージデータセットのバッチ処理向けの使いやすいプラットフォームを提供してきました。ただし、現在のバイオインフォマティクスパイプラインへの十分な代替としてこのようなツールを使用するには、ゲノムデータ処理向けのアクセス可能かつ包括的なAPIが必要になります。さらに、これらの処理されたデータセットの相互探査向けのサポートも必要です。 ADAMおよびMangoは、Apache Sparkにおけるラージゲノムデータセットを処理、フィルタリング、視覚化するための統合環境を提供します。ADAMにより、Apache Spark内のデータを収集および選択するためのSpark SQL、SQLインターフェイスを使用して、未加工のゲノムおよび各種データをプログラム的にロード、処理、選択することができます。Mangoは、Jupyterノートパソコン環境において、未加工および収集されたゲノムデータの視覚化をサポートしています。複数の解像度のラージデータセットから結果を出すことができます。

Autodesk は 3D 設計、エンジニアリング、エンターテイメントソフトウェアのリーダーです。Autodesk は物を作る人のためのソフトウェアを作成しています。高性能の車を運転したり、超高層ビルを見上げたり、スマートフォンを使用したり、偉大な映画を見たりしたことがある人は、何百万人もの Autodesk ユーザーがソフトウェアで行っていることを体験したことがあると思われます。 Autodesk は Amazon RDS で稼働するマネージド MySQL データベースと Amazon EC2 でホストされるセルフマネージド MySQL データベースの両方からAmazon Auroraに移行しました。このブログ記事は、その経験をまとめ、次の点について取り上げます。 Autodesk の Amazon Aurora への移行決定に影響を与えた要因 移行上の特定の利点 移行と最適化に関して学んだベストプラクティスと教訓 まず、クラウドで生まれた Autodesk Access Control Management (ACM) アプリケーションの移行パスを確認します。始めに Amazon RDS for MySQL を選択し、スケーラビリティ、可用性、およびパフォーマンスを向上させるために Aurora に移行しました。ACM が移行を問題なく完了させたことで、Autodesk の他のいくつかのアプリケーションが Aurora に移行する意欲が高まりました。EC2 でホストされているセルフマネージド MySQL データベースを Amazon Aurora に移行する主要な例として、BIM 360 Field Classic について説明します。 […]

みなさん、こんにちは。 アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。 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分かかります。