Category: 利用事例


Hightail — クラウド上での創造的なコラボレーションを支援

Hightail (旧社名: YouSendIt) は、世界各地の 5,000 万人以上の専門家が優れたコンテンツをユーザーに提供できるよう支援することで、創造的な作業の確認、改善、承認方法を合理化しています。Hightail は、ファイル共有会社として 2004 年に設立されて以来、付加価値のある創造的なコラボレーションサービスの提供へと戦略的方向を転換し、著名な顧客を数多く獲得しています。

本日のゲスト投稿では、Hightail の技術担当上級副社長である Shiva Paranandi 氏が、同社が実施したオンプレミスからクラウドへのペタバイト単位のデータ移行について語ります。クラウドベンダーの評価プロセスと、すべてを AWS に移行した理由が述べられています。


Hightail はユーザーが大きなファイルを簡単に共有して保存できる方法を提供するために設立されましたが、それ以降、創造的なコラボレーションツールへと進化してきました。当社は、ユーザーがデジタル資産を管理、共有するだけの場所ではなく、創造的なチームを作り、顧客とつながり、創造的なワークフローを開発して、最初から最後までプロジェクトを管理できる場所になりました。現在では、LionsgateJimmy Kimmel Live! といった有名ブランドのコラボレーションサービスの原動力となっています。当社は、国内外の顧客が増える中で、製品開発とユーザーへのサービスに対して社内的により傾注する必要がありました。独自のデータセンターの運営には、予定していたよりも多くの時間、費用、人材が必要になることがわかりました。

より迅速に反復して顧客のニーズを満たし、市場までの時間を大幅に改善する手法が必要でした。データセンターのコストを削減し、世界各地の特定のリージョンで迅速にスケールアップする柔軟性が必要だったのです。新しい場所でのデータセンターの設営には長い時間がかかり、当社が達成できる成長ペースの妨げとなっていました。さらに、使用することもないストレージキャパシティーを所有することになる、ニーズに先回りした購入にはうんざりしていました。頻繁に使用しないデータを非アクティブなストレージに保持する一方で、顧客のリクエストに応じてそのデータを迅速に取り出せることでコストを削減する、階層型で非常にスケーラブルなストレージソリューションが必要でした。当社の主な推進力は俊敏性と革新であり、クラウドはそれらを強力に可能にしてくれます。それを踏まえて、ストレージとコンピューティングインフラストラクチャの管理にリソースを投入するのではなく、ビジネスを差別化する構想に時間とコストを費やすことができる、クラウドファーストのポリシーを採用することに決定しました。

AWS とクラウド競合他社の比較

移行の開始にあたって、まず AWS、Google、IBM、Microsoft を含むさまざまなクラウドベンダーの評価を行いました。当社にとっては明らかに AWS が抜きん出た選択肢でした。ある時点では、ニーズを満たすために複数のクラウドプロバイダーからのサービスを組み合わせることを検討しましたが、最適なルートは AWS を単独で使用することであると判断しました。トレーニング、同期、サポート、システムの可用性、それに他の移行や管理の要素を考慮すると、複数のクラウドを使用する手法は実用的ではありませんでした。最善のコスト削減と、ほかに例を見ないパートナーソリューションのエコシステムにより、他のベンダーは必要なく、すべてを AWS に移行することを選択しました。

AWS に移行することで、ギガバイトあたりの最低料金、リッチなエコシステムへのアクセス、社内の迅速な人材開発、SOC II コンプライアンスの維持が可能になりました。エコシステムは特に当社にとって重要で、非常に多くのパートナーを持つ AWS は競合他社とは一線を画していました。実際に、イメージのプレビュー、ビデオのエンコード、プレゼンテーションの提供などのサービスについて当社が依存しているすべてのベンダーは既にこのネットワークに参加しているため、既存の投資や専門知識を簡単に利用することができました。別のプロバイダーを選択していれば、既に正しく稼働しているプラットフォームからの移行が必要になりますが、これは当社にとって望ましい結果ではありませんでした。また、AWS のテクノロジーについて社内で開発できる人材の数も驚くべきものでした。AWS の使用に関する内部チームのトレーニングは、AWS カンファランス、トレーニング教材、サポートなどの利用可能なツールを使用した簡単なプロセスです。

ペタバイト単位のデータの移行

AWS を選択したことで、作業が簡単になりました。多くの場合、社内で使用していたよりも優れた機能が提供されました。オンプレミスストレージから AWS に数ペタバイトのデータを簡単に移行できました。AWS の Direct Connect により高速に処理を進めることができたため、3 か月ほどですべてのデータをプッシュできました。それによるユーザーへの影響はありませんでした。AWS Key Management Service を採用してデータを安全に保ち、それにより移行の際の安心感が得られました。顧客への影響が低いことを確認するため、当社データセンターと AWS にプッシュされたデータ間のチェックサムなどの方法を使用して、事前に広範な QA テストを実行しました。

AWS 上の新しいプラットフォームにより、ユーザーエクスペリエンスが大きく改善しました。信頼性、パフォーマンス、稼働時間において大きな改善が見られました。これらは当社の業務においてすべて非常に重要です。現在では、以前のデータセンターよりも最大 17 倍高速なアップロードおよびダウンロード速度を達成することができ、稼働時間も桁違いに向上しています。また、新しいリージョンへのサービスのデプロイにかかる時間も、90% 以上削減できました。以前は、新しいリージョンをオンラインにするには少なくとも 6 か月かかっていましたが、現在では、3 週間以内でリージョンを立ち上げることができます。AWS では、災害対策の目的で、リージョン間でデータをバケットレベルでレプリケートすることもできます。

コストを削減するため、ストレージインフラストラクチャを、アクセス頻度が高いデータと低いデータに分類することができました。Amazon S3 の階層化ストレージは大きな利点であり、これによりストレージコストを最適化することができ、製品開発へのより多くの投資が可能になっています。現在では、顧客のニーズを満たすために非アクティブ階層からアクティブ階層にデータを瞬時に移動でき、ストレージインフラストラクチャを過剰プロビジョニングする必要がなくなりました。ピーク負荷の時間中にサービスが自動的に拡張または縮小するのを見て、必要な分だけの支払いで済んでいることを知るのは爽快です。

全体として、当社はインフラストラクチャではなく開発により多く集中するという主要な戦略目標を達成しました。当社の移行はシームレスに感じられ、ここでお伝えできる進歩こそが、ワークロードを AWS で実行するのがいかに簡単であるかの真の証です。移行の成功要因の一部として、AWS チームから提供された専用サポートが挙げられます。サポートは本当に素晴らしいものでした。何人かの技術者は 24 時間 365 日チャットに対応してくれましたが、これは大規模な移行では不可欠なものでした。

-Shiva Paranandi 氏、Hightail 技術担当上級副社長

詳細

Amazon S3 によるコスト効率の高い階層型データストレージの詳細について参照するか、AWS パートナーエコシステムで、お客様のニーズに最適なソリューションをお探しください。

AWS HIPAA 対応サービス発表についての詳細情報

AWS では、HIPAA 対応サービスの発表がいくつかありました。AWS ヘルスケアおよびライフサイエンスグローバルテクニカルリーダーの Patrick Combes、および AWS ヘルスケアおよびライフサイエンスパートナーソリューションアーキテクトの Aaron Friedman が、その全貌についてお知らせするためにこの投稿を書いています。

-Ana


ここ数週間の間に、次の AWS のサービスが BAA に追加されたことをお知らせいたします。 Amazon API GatewayAWS Direct ConnectAWS Database Migration ServiceAmazon SQS。これら 4 つのサービスはすべて AWS へのおよび AWS を通じてのデータの移動を容易にするため、お客様がこれらのサービスを使用してヘルスケアにおけるソリューションをどのように促進できるか楽しみです。これらのサービスのそれぞれのユースケースは膨大なので、お客様が Protected Health Information (PHI) でこれらのサービスを使用できるいくつかの方法を取り上げます。

AWS の事業提携の追補 (BAA) の適用を受けるすべての HIPAA の対象サービスと同様に、PHI は、保管時または転送時に暗号化される必要があります。HIPAA のホワイトペーパー を参照することをお勧めします。これは、PHI を保存、処理、および転送するための AWS の HIPAA 対応サービスの設定方法について説明しています。そしてもちろん、PHI に該当しないアプリケーション部分については、90 以上のサービスを使用して、ユーザーに最適なエクスペリエンスを提供することができます。HIPAA のアーキテクチャに関するアイデアは、ウェブサイトでご覧いただけます。

Amazon API Gateway
Amazon API Gateway は、ウェブサービスで、開発者はこれを利用することにより、あらゆる規模で、簡単に API の作成、配布、監視、保護が行えます。PHI を使用して、API Gateway を安全に通過することができるようになりました。患者/プロバイダディレクトリ、患者ダッシュボード、医療機器レポート/テレメトリー、HL7 メッセージ処理などのアプリケーションは、AWS またはクライアントプレゼンテーションレイヤー内で実行している任意の数と種類のアプリケーションに情報を安全に受け入れ配信できます。特に楽しみなのは、ヘルスケア情報を交換するうえで Amazon API Gateway をお客様がどのように活用するかです。Fast Healthcare Interoperability Resources (FHIR) 仕様は、エンティティ間で医療情報を共有する方法に関する次世代の標準となりそうです。RESTful アーキテクチャを強力にサポートすることにより、FHIR は、Amazon API Gateway の API 内で簡単に体系化することができます。FHIR の詳細については、AWS 医療コンピテンシーパートナーである Datica に、優れた入門書があります。

AWS Direct Connect
Johnson & Johnson のような当社のヘルスケアおよびライフサイエンスのお客様の一部は、ハイブリッドアーキテクチャを活用し、オンプレミスインフラストラクチャを AWS クラウドに接続する必要があります。AWS Direct Connect を使用すると、AWS とデータセンター、オフィス、またはコロケーション環境間にプライベート接続を確立することができます。これにより、多くの場合、ネットワークのコスト削減、帯域幅のスループットが向上し、インターネットベースの接続よりも均質なネットワーク体験を提供できます。ハイブリッドアーキテクチャ戦略に加えて、AWS Direct Connect は、AWS への安全なデータ移行を支援することができます。これは Amazon S3 や Amazon EMR など、PHI の保管と処理に HIPAA の対象サービスを幅広く使用するための第一歩です。さらに、サードパーティー/外部でホストされたアプリケーションやパートナー提供のソリューションに接続したり、エンドユーザーをクラウドベースの電子カルテシステムなどの同じヘルスケアアプリケーションに安全かつ確実に接続することができます。

AWS Database Migration Service (DMS)
現在までに、お客様は、AWS Database Migration Service を通じて 20,000 を超えるデータベースを AWS に移行しました。お客様は、クラウド移行戦略の一環として DMS を使用することが多く、今やそれを PHI を含むコアデータベースを安全かつ容易に AWS クラウドに移行するために使用することもできます。DMS を使用した移行中でもソースデータベースは完全に利用可能な状態に保たれるので、データベースを AWS に移行する際に、ビジネスクリティカルなアプリケーションのダウンタイムは最小限に抑えられます。このサービスは、患者ディレクトリ、支払い/トランザクションレコードデータベース、収益管理データベースなどのアイテムを AWS に安全に転送するために利用できるようになりました。

Amazon Simple Queue Service (SQS)
Amazon Simple Queue Service (SQS) は、あらゆる規模での、分散されたソフトウェアコンポーネントおよびマイクロサービス間での信頼性の高い通信のためのメッセージキューイングサービスです。想定されるお客様による PHI での SQS の使用方法は、HL7 または FHIR メッセージをアプリケーションの他の部分に渡すアプリケーションコンポーネント間の要求をバッファすることです。PHI を含むメッセージが、受信した順に渡され、受信した順に配信され、使用者が処理して削除するまで使用できるように、SQS FIFO などの機能を活用できます。これは、病院での患者記録の更新または支払い情報の処理を行うアプリケーションにとって重要です。

では、始めましょう。
ヘルスケアアプリケーションの一環として、新しい HIPAA 対応サービスをお客様がどのように使用されるのか、とても楽しみです。あなたが一番楽しみにしているのはどんな点ですか。下にコメントを残してください。

AWS でコンソーシアムサイエンスを活用し科学的発見を促進

同僚の Mia Champion は科学者 (彼女が発表した記事) であり、AWS 認定ソリューションアーキテクト そして AWS 認定開発者でもあります。今回は、彼女が大量なデータのデータセットリサーチを行っている際に、バイオインフォマティクスにおけるクラウドコンピューティングの価値に気付いた時のことについてブログを投稿いただきました。

Jeff;


科学研究における技術の進歩は、そのコンテンツにおいても複雑性を増し、日々急増しているデータセットのコレクションに可能性を与えています。世界中で加速化するイノベーションは、最近のクラウドコンピューティング革命によっても活気付けられ、一見したところ無限でスケーラブルそして迅速なインフラストラクチャを研究者に提供しています。現在では、研究者が独自のシーケンサー、マイクロスコープ、コンピューティングクラスターなどを所有するための障害を排除しています。クラウドを使用することで、科学者はギガバイトにも及ぶ何百万人という患者のサンプルのデータセットや各患者のその他の情報を簡単に保存、管理、処理そして共有することができます。アメリカの物理学者である John Bardeen はこのように言っています。「科学というものは協同して取り組むものです。数人の科学者が共に努力し出し合った結果を組み合わせることで、1 人の科学者が行うよりも効率よく研究を進めることができるのです (Science is a collaborative effort. The combined results of several people working together is much more effective than could be that of an individual scientist working alone)」

再現性のイノベーション、一般化、データ保護の優先
これまでにないスケールで、安全性を備えたクラウドを有効にしたデータ共有を活用する研究者や組織は日々増え、AWS クラウドを使用して革新的でカスタマイズした分析ソリューションを作り出しています。しかし、そうしたスケールの共同作業環境において、対象分野そして科学における従来の方法を根本的に変え、安全なデータ共有と分析を行うことは可能でしょうか?クラウドを有効にしたリソースの共同体を構築することで、研究結果の説明やその影響において問題となり、再現性の下落に繋げた分析変動性を排除することはできるのでしょうか? こうした疑問への答えは「イエス」です。Neuro Cloud Consortium、The Global Alliance for Genomics and Health (GA4GH)、The Sage Bionetworks Synapse プラットフォームのようなイニシアティブは (これは、いくつものリサーチコンソーシアムをサポートしています)、DREAM challenges も含み、プラクティスモデルのクラウドイニシアティブを取り入れ始めています。そして、これらは神経科学、感染病、癌などにおいても大きな発見を提供しているだけでなく、科学研究の在り方についても根本的な変化をみせています。

クラウドで開発するモデル、アルゴリズム、機能をデータに取り入れる
従来、共同プロジェクトでは研究者が相対的な配列分析や医用画像データでディープラーニングアルゴリズムのトレーニングにて使用されるデータセットをダウンロードするようになっていました。そしてダウンロード後に、研究者は組織のクラスター、ローカルワークステーション、ノートパソコンを使用して独自の分析を開発し実行することができます。

この方法で行う共同作業は問題となるいくつもの理由があります。まず、データセキュリティが最初の懸念です。データセットをダウンロードする方法では、その情報が何人もの受信者に渡り「連鎖したデータ共有」を許可してしまうことになるからです。そして次に、何らかの段階でテンプレートを使用せずにコンピューティング環境で行った分析は変数解析のリスクを伴い、それ自体を別の研究者が再現することはできません。また、同じ研究者が別のコンピューティング環境を使用した場合も同様です。さらに、必須とされるデータのダンプ、プロセスそして共同作業のグループへの再アップロードやディストリビューションは効率的とは言えず、各個人のネットワーキングやコンピューティング能力に依存することになります。全体的に見て、従来の科学的な共同作業を行う方法にはセキュリティ問題や科学的発見に費やす時間において障害を伴います。AWS クラウドを使用することで、共同作業を行う研究者達は Identity and Access Management (IAM) ポリシー制限をユーザーのバケットアクセスや、S3 バケットポリシー、アクセスコントロールリスト (ACL) で利用することにより、簡単かつ安全にデータセットを共有することができます。データソースに分析を移動するリソースを使用したり、リモート API リクエストを利用して共有データベースやデータレイクにアクセスする方法を取り入れることで、多くの研究者達はデータセットをダウンロードする必要性を排除し、分析を効率化してデータセキュリティを確保しています。この達成方法の 1 つとして、当社のお客様は共同作業を行うユーザー達にアルゴリズムを送信または共有したデータセットをホストするシステムで実行するモデルを提供することで、コンテナベースの Docker テクノロジーを利用しています。

Docker コンテナイメージにはアプリケーションへの依存関係すべてが含まれています。そのため、レベルの高い多彩性や可搬性を提供することができ、これは他の実行可能ベースのアプローチの使用に比べ、大きなメリットになっています。機械学習の共同プロジェクトにおいては、各 Docker コンテナにアプリケーション、言語ランタイム、パッケージとライブラリ、その他にも MXNetCaffeTensorFlowTheano など、研究者達が一般的に使用している人気のディープラーニングフレームワークが含まれています。こうしたフレームワークで一般的に見られる機能は、機械学習の計算に関与するマトリックスやベクトルオペレーションホストマシンのグラフィック処理ユニット (GPU) があります。こうした目的を持つ研究者達は EC2 の新しい P2 インスタンスタイプを利用して、送信された機械学習モデルを実行しています。さらに NVIDIA Docker ツールを使用して、GPU を追加デバイスとしてシステムレベルに見せてコンテナに直接マウントすることができます。Amazon EC2 Container ServiceEC2 コンテナレジストリを利用することで、共同作業を行っている研究者達は同僚が再現可能な方法でプロジェクトリポジトリに送信した分析ソリューションを実行することができます。また、既存の環境で引き続き構築することも可能です。研究者は継続的なデプロイパイプラインを設計することで、Docker を有効にしたワークフローを実行することもできます。つまり、クラウドを有効にしたコンソーシアムイニシアティブは、幅広いリサーチコミュニティで精密医療分野における科学的発見を促進させながら、プロジェクトを実施する上でデータセキュリティや再現性を持つ、科学的発見が自然に必要とするプラットフォームをサポートすることも可能にしたモデルの役割を担っているのです。

Mia D. Champion, Ph.D.

Streamlineのケーススタディ:Amazon GameLiftで加速リリース

Screenshot_ProletariatQuote_V2

Proletariatについて

ボストンに拠点を置くProletariatは、革新的なマルチプレイヤー体験の構築に焦点を当てたインディーゲーム企業です。5人のゲーム業界のベテランによって2012年に設立されました。彼らは、賞を獲得したWorld Zombinationの立案者です。World Zombinationは、プレイヤー同士が共に戦略を立て合ってゾンビや人間の大群を用いて街を破壊したり守ったりする巨大なオンラインゲームです。彼らの最新のマルチプレイヤーゲームであるStreamlineは、オーディエンスのインタラクティブなゲーム参加が特徴であり、ストリーミング配信者や視聴者が試合中にゲームプレイルールをリアルタイムに変更することができます。

課題

Proletariatは、3月のGDC 2016でStreamlineを公表し、ゲームストリーマーのプレミアムイベントである9月のTwitchCon 2016でベータ版を公開する予定であると告知していました。しかし、TwitchCon 2016のTwitch Prime一般公開に含めないかという話をAmazonが持ちかけたところ、ProletariatはStreamlineを誰でもプレイできるようにするために開発を加速することを決めました。彼らは興奮する一方で、自分たちの独自のゲームサーバソリューションが、管理に手間がかかり過ぎることと増加していくプレイヤー需要をサポートするために必要な機能が足りていないことを気にしていました。

Proletariatの独自のクラウドソリューションはAWS Elastic Container Service (ECS)を中心に構築されていました。AWS ECSは、AWS EC2インスタンス上のアプリケーションの管理を容易にしてくれるコンテナ管理のサービスです。サーバのヘルスチェックを実行したりプレイヤーを利用可能なゲームサーバに接続するなど、彼らは基本的なゲームサーバの機能を手動で操作していました。これらのプロセスによってプレイヤーの負荷が処理されますが、Streamlineが一般利用可能になってしまえば管理は手間がかかり過ぎるでしょう。また、彼らの独自のクラウドソリューションは、どのゲームサーバがアクティブなゲームセッションを保持しているかというこを特定することができませんでした。これは、サーバのキャパシティを手動で調整している間に誤ってアクティブなゲームセッションを縮小し、プレイヤーをStreamlineから切断してしましまう可能性があることを意味していました。単一のEC2インスタンス上で複数のゲームサーバプロセスを実行することができないので、テストをシンプルにすることも困難でした。各ゲームサーバはユニークな公開ポートを必要としますが、コンテナ内部からはその公開ポートを取得することができませんでした。

Proletariatは、ゲームサーバのホスティングにAWSの実績のあるインフラストラクチャを使い続けることを希望していましたが、必要な機能を構築するには数千時間はかかりそうでした。あっという間ににTwitchCon 2016の開催は近づき、ProletariatはAmazon GameLiftを紹介されました。Amazon GameLiftはAWSのマネージドサービスです。ゲームサーバのホスティングをシンプルにしサーバキャパシティを数分でスケールします。

「Proletariatのチームにとって選択肢は非常にシンプルでした。つまり、我々のクラウドインフラストラクチャを構築するのに数ヶ月を費やすためにエンジニアチームを雇うか、あるいはAmazon GameLiftで数分でデプロイするか、です。」とProletariat社CEOの Seth Sivakは言いました。

実装

Proletariatは、Amazon GameLift Server SDK for C++をダウンロードしUnreal Engineゲームサーバのビルドに統合し、ゲームサーバをAmazon GameLiftにアップロードしました。Unreal Engineゲームサーバを格納するために、5つのGameLiftインスタンスタイプのどれが自分たちのニーズに最も適しているかを判断する必要がありました。「リアルタイムゲームでは、ネットワークが最適化されたAmazon GameLiftインスタンスが必要でした。そのため、私達は一連のインスタンスにc4.xlarge.gameliftを選択しました。」とStreamlineのリードエンジニアである Cauê Waneck は言いました。「Amazon GameLiftは、各インスタンス上で4つのゲームサーバをサポートするように実行設定を構成することができます。これは、私達のゲームサーバがシングルスレッド構成であることを考えると完璧です。これにより、vCPUあたり1つのゲームサーバプロセスをうまく活用できるようになり、テストとイテレーションのプロセスが大幅にシンプルになります。」

独自に作成したNode.jsのマッチメイキングシステムとAmazon GameLift上のC++のゲームサーバ間のゲームセッションの新規作成を管理するために、ProletariatはAWS JapaScript SDK with Amazon GameLiftを使用しました。また、彼らはクイックマッチに利用可能なキャパシティを持つゲームサーバを見つけるために特殊なゲームセッションデータを使用しました。このデータは、サーバが新規プレイヤーを受け入れるべきかどうかを分類し、どのゲームセッションが利用可能なプレイヤースロットを持っているかを特定するのに役立ちました。「Amazon GameLiftは、大量のプレイヤーのマッチメイクを容易にし、待ち時間を減少させました。」とWaneckは言いました。「さらに、ゲームセッションをパーティーリーダーに関連付けるということが可能だったので、プレイヤーにカスタムゲームマッチの開催を可能にするというかたちでも役に立ちました。」

Proletariatは、アクティブなゲームを保持するインスタンスがスケールダウンされてプレイヤーをオフラインにしてしまうことを防ぐために、Amazon GameLift組み込みのゲームセッション保護の有効化も行いました。「Amazon GameLiftは保険のようなものです。サーバのスケーリング、とりわけ起動時のスケーリングにおいて安心を与えてくれます。」とWaneckは言いました。

AWS Command Line Interface (CLI) with Amazon GameLiftによって、彼らのビルドシステムにロジックを実装するときに新しいインスタンス群を起動してコマンドを再利用することが容易になりました。ゲームクライアントの更新をデプロイする際に、シンプルなコマンドを使用してAmazon GameLiftのエイリアスを利用し、プレイヤーを1つのインスタンス群から別のインスタンス群にダウンタイムなしで移動させました。また、CLIを使用して世界中のリージョンにゲームサーバをたった数分で起動しました。「Amazon GameLiftチームは私達を全面的にサポートしてくれました。私達が運用上の問題に取り組むのを助けるために24時間365日彼らがいてくれたのは嬉しいことです。」とWaneckは言いました。

わずか5日間で、ProletariatはAmazon GameLiftを使用し自信を持ってTwitchCon 2016にStreamlineをリリースしました。Amazon GameLiftによって数千時間の開発時間が節約され、代わりにStreamlineのコアである革新的なゲームプレイに磨きをかけることに専念しました。

詳細情報

Amazon GameLiftを用いた専用のゲームサーバのホスティングやスケーリングの方法の詳細をご覧ください。Streamlineについての詳細はplaystreamline.comをご覧ください。

(翻訳はSA 畑が担当しました。原文はこちら)

Human Longevity, Inc. – ゲノム研究で医療を変える ゲノム研究の先端をリードする

Human Longevity, Inc. (HLI) は予防衛生を支持する上で、ヒトゲノムおよび関連性を持つ表現型データや臨床データを蓄える世界最大のデータベースを構築したいと考えています。今回のゲスト投稿では、Yaron Turpaz 氏と Bryan Coon 氏、Ashley Van Zeeland 氏が医学に大きな変化をもたらす努力の一端として生成している大量のデータを保存するため、どのように AWS を使用しているのか語ります。

Jeff;


2013 年に Human Longevity, Inc. を設立した当時から、前途に待ち受ける挑戦を認識していました。ゲノムには生命体を形成し維持する上で必要なすべての情報が詰まっています。ヒトにおいては、30 億もの DNA ベースのペアを含むゲノム全体のコピーが核を持つ全細胞に含まれています。我々の目的は 100 万のゲノムを配列し、その情報と関連付けた健康記録や疾病リスクを研究者や医師に提供することです。研究者や医師はデータを解釈して的を絞った個人の健康管理プランや、癌やその他の深刻な健康リスクにおいて最適な治療を従来より遥かにすばやく提供することができます。従来のように症状が出始めてから医師にかかり、病気を診断されてから治療を始めるモデルではなく、予防衛生やリスク予防を発展させることで医療を変えることが我々の目的です。大規模なコンピューティングを開発し適用、ゲノム研究に機械学習を使用するには Illumina のような企業が提供する DNA 配列技術による大量なデータの収集、分析、保存が必要になります。1 つのゲノムからの生データは約 100 ギガバイトを消耗します。注釈や表現型のソースや分析を含むゲノム情報を調整し、健康上の情報を分析するに伴ってこの数字は上昇します。我々が選ぶコンピューティングとストレージ技術が当社の成功に直接影響することは初めから理解していました。ですから、クラウドを使用することは明らかに最適な選択でした。当社はゲノミクスを専門としているので、IT インフラストラクチャの構築や維持にリソースを使用することは希望していません。そこで、プラットフォームの広さや当社が必要とする優れたスケーラビリティ、そしてビッグデータで展開した専門知識を備えている AWS を選ぶことにしました。また、AWS によるイノベーションのペースも考慮しました。利用者のために可能な限りコストを抑える AWS の手の込んだ策略も、当社のビジョンを実現する上で非常に大切なポイントだと考えました。

広範囲にわたる AWS サービスの活用

 スペクトルの核型分析 / 画像提供: Human Longevity, Inc.

スペクトルの核型分析 / 画像提供: Human Longevity, Inc.

現在、当社では広範な AWS サービスを使用して様々な種類のコンピューティングタスクやストレージタスクを行っています。たとえば HLI のナレッジベースは Amazon S3 ストレージと多数の Amazon EC2 ノードで構成される分散システムインフラストラクチャを活用しています。これにより、当社がリソースの分離やスケーラビリティ、迅速なプロビジョニング、ペタバイトスケールのデータベースクエリや動的なコホートビルダーに対し、ほぼリアルタイムの応答時間を可能にすることができました。AWS サービスの柔軟性により、当社のカスタマイズした Amazon Machine Image や事前構築の BTRFS 分割した Amazon EBS ボリュームで起動時間を数分ではなく数秒にすることもできました。当社が必要とする規模でデータレイクに対し Spark クエリを実行する場合には Amazon EMR を使用しています。AWS 関数は Amazon S3 イベントに接続したり、アプリと連携したり、すでに対応済みのビジネスロジックを含むコードをドロップするのに優れたツールです。当社はデマンドベースの Auto Scaling を使用し、Docker パイプラインの管理には AWS OpsWorks を使用しています。We also leverage the cost controls provided by Amazon EC2 スポットやリザーブドインスタンスタイプが提供するコスト管理も使用しています。当初はオンデマンドインスタンスを使用していましたが、コスト面で負担が急増しました。スポットインスタンスやリザーブドインスタンスでは、特定のニーズやワークフローに基づいてコンピューティングリソースを割り当てることができます。AWS サービスの柔軟性により、Apache Mesos が提供するリソース管理サービスを介して Docker サイズのコンテナをフル活用することも可能です。永続的およびスポット抽象化レイヤーにある何百もの Amazon EC2 の動的ノードは、使用量の需要や AWS 料金の最新情報に合わせてスケールアップしたりスケールダウンするよう、動的に調整されています。この動的にスケールされるコンピューティングクラスターと当社のナレッジベースサービスや社内のゲノミクスおよび腫瘍のコンピューティングパイプラインを共有することで多大な節約を実現しています。この柔軟性のおかげで、当社が必要とする処理能力を利用しながらコストを抑えることが可能になっています。こうした選択により、オンデマンドモデルを使用していた時に比べコンピューティングに掛かる費用を 50% 削減することができました。また、当社は AWS プロフェッショナルサービスを利用して特定のハードデータストレージにおけるチャレンジにも取り組みました。当社は Amazon S3 バケットに何百ものゲノミクスデータを保存しています。その多くはペタバイトレベルで何十億ものオブジェクトを含んでいます。中には未使用または 1 度か 2 度使用し再使用することのない何十億ものオブジェクトがあります。何十億というオブジェクトの中から 1 つを見つけることは大変なタスクです。Amazon S3 の頻繁にアクセスしないストレージクラスに当てはまるファイルやファイル形式がどれか識別する場合にさらなる負荷が掛かってしまいます。そうした状況でプロフェッショナルサービスは Amazon S3 オブジェクトのインデックス作成をソリューションとして提供し、当社の時間とコスト節約を可能にしました。

スピードの上昇とコスト削減
遺伝子配列とクラウドコンピューティングという 2 つの重要なテクノロジーの変曲点において、当社はタイミング良く AWS を選ぶことができました。つい最近まで、1 つのゲノム配列には 1 年間と約 1 億ドルの費用が掛かっていました。今では 1 つのゲノム配列に 3 日と数百ドルのコストが掛かる程度です。スピードとコスト低下の劇的な改善、可視化と分析ツールの急速な進展により、ほぼリアルタイムで大量のデータを収集し分析することが可能になりました。従来は何か月、何年と掛かっていたプロセスも、今ではユーザーがデータに基づく疾患性の検証を数日あるいは数時間で行うことができるようになりました。最終的には、これが患者の利益になるのです。当社のビジネスには HLI Health Nucleus があります。これはホールゲノム配列分析、高度な臨床画像、機械学習、収集し要約した個人の医療情報を使用し、ゲノミクスを利用する臨床研究プログラムで個人の健康の全体像を表す情報を提供します。当社では、これにより医師が病を識別し治療や予防を劇的に向上させ、患者の長期生存とより健康的なライフスタイルを可能にできると考えています。– Yaron Turpaz (最高情報責任者)、Bryan Coon (エンタープライズサービス部長)、Ashley Van Zeeland (最高技術責任者)

詳細
AWS が クラウドでゲノミクスをサポートする方法やゲノミクスのイノベータ―である Illumina が AWS を使用して遺伝子配列のスピードを促進しコスト効率を高めている方法をご覧ください。

ゲノムエンジニアリングのアプリケーション: クラウドを早期導入

オーストラリア連邦科学産業研究機構 (Commonwealth Scientific and Industrial Research Organization (CSIRO)) から、重要な新しいゲノム編集技術で AWS が活用されている件について寄稿いただきました。– Jeff


最近の分子工学技術ではゲノム編集を正確に行えるようになりました。この CRISPR-Cas9 という新技術は独自の DNA 配列でパターンマッチングを行い、ゲノム内で特定の場所を識別し編集できるようにプログラムすることが可能です。これは研究者にとってパワフルで新しいツールですが、ゲノム全体にわたりターゲットをスキャンし探すということは、これまでにない大規模なコンピューターの使用が必要であることも意味しています。今年始めにアメリカ国立衛生研究所 (US National Institutes of Health (NIH)) はヒトの健康においてこうした技術の使用を承認しました。これはがん治療に革命を起こす可能性を秘め、計算力においてもスピードが重視されることを意味しています。がん治療の新しいアプローチ およそ 5 人に 1 人はがんにかかるといわれている昨今、がん生存率は 2 倍になったといわれていますが、脾臓がんの場合はその確率が 1 % といったように生存率の低い種類のがんはまだあります。その理由は、主に健康な細胞組織に害を加えずに、がん細胞を消滅させる治療的介入を見つけることが困難だからです。従来とは異なる治療法を開発する上で、NIH が新たにトライアル承認した CRISPR-Cas9 はゲノム編集技術において飛躍的な進歩を可能にします。自然にがんと闘う細胞の特異的修飾により、患者は自分の免疫システムを強化させることができます。特定の血液がんや固形がんまたは黒色腫を患う患者を含む、現在行っている研究で幅広い範囲にわたり、この技術は異なる腫瘍に対し効力を発する可能性を持っています。計算に基づいたゲノムエンジニアリングにおけるクラウドサービスヒトの健康を対象としたこの新しいアプリケーションは、臨床ケアの時間的制約に応えるため CRISPR-Cas9 デザインの堅牢性と効率性を必要としています。AWS クラウドサービスをベースにして eHealth プログラム、オーストラリ連邦科学産業研究機構 (CSIRO) は、この問題に取り組むために新型のソフトウェアツール、GT-Scan2 を開発しました。「他の方法に比べて GT-Scan2 は遺伝子位置を高感度かつ特異性をもって特定することができます」と、トランスフォーメーショナルバイオインフォマティクスチームを率いる Dr. Denis Bauer は語っています。

GT-Scan2 はゲノム位置で特定した CRISPR ターゲットの位置を示し、その高アクティビティや低アクティビティを記述するほか、オフターゲットの可能性も表示します。

GT-Scan2 はゲノムで独自の位置を見つけることでシステムの効率性を高めます。これによりゲノム内にある別の位置で配列相同性が高い「オフターゲット」によって影響力を弱められないようにします。変更しやすい位置を見つけることで堅牢性を最適化します。「ゲノムの 3D 構成が CRISPR バインディングの役割を担うことはすでに知られていましたが、GT-Scan2 は Cas9 アクティビティにとって重量となる別のコンポーネントも活用する最初のツールです」と、コンピュテーショナルゲノムエンジニアリングを研究する Dr. Laurence Wilson は述べています。特にオフターゲット検索は数値計算タスクで各ロケーションにつき 30 億文字列という非常に長いゲノム配列を調査する必要があります。そのため、従来は高性能な計算力を備えたインフラストラクチャを持つ大規模な組織の研究者が行うタスクでした。GT-Scan2 は AWS Lambda 関数を使用し、この複雑な計算力をクラウドサービスとして提供することで、最適位置を見付けることができます。パーソナライズ治療を瞬時にスケール GT-Scan2 はイベント駆動型の AWS Lambda サービスが提供するすばやいスケーラビリティを利用します。標的化遺伝子は劇的に変動するため、これはパーソナライズ治療において非常に大切です。「オフターゲットの研究や堅牢性の分析は並行して実行できる各モジュラータスクに分けることができます」と、Aidan O’Brien は述べています。同氏は、AWS Summit 2016 で今年 4 月のアジアパシフィックリリースから数週間内にこのシステムを設計し導入、さらにそのサービスの直観的な性質を証明しています。通常、1 つのジョブの所要時間は 1 分未満でジョブ間の変動時間は 1 秒から 5 分です。数分内というロード時間の迅速な変動は、ランタイムの安定性を維持するにはオンラインになるのが遅すぎロードに数時間を要する新しいインスタンスとしての EC2 ベースソリューションを除外します。

GT-Scan2 は S3 で提供、サーバー側からの処理なしに静的ウェブアプリを実行できるようにします。JavaScript フレームワークを使用して、データベースから API Gateway を使い API コール経由で動的コンテンツ (ジョブの結果やパラメーター) を取得します (DynamoDB)

ユーザーがジョブを送信すると、GT-Scan2 が API コール経由で DynamoDB テーブルにアイテムとしてジョブパラメーターを挿入します。これにより、ボトルネックを作らず自由でスケーラブルなソリューションを可能にします。このデータベースエントリは最初の Lambda 関数をアクティブ化し、ユーザー専用の DNA 配列 (ユーザーの送信時に自動取得) で推定上の CRISPR ターゲットをすべて検索します。CRISPR ターゲット候補の位置には一定のルールがあり、数秒で完了する 2 つめの DynamoDB テーブルに挿入される正規表現を使用して簡単に探すことができます。Lambda ベースのマイクロサービスを活用 ターゲット候補はすべて効率的なマッチングツールの Bowtie を使用してそのオフターゲットリスクを評価する必要があります。Bowtie では 30 億の文字列から形成されるゲノム配列の簡約表示のみが必要となるので、こうしたインデックスファイルのサイズが各 Lambda インスタンスのストレージ制限を超えることはありません。開発時に CSIRO チームをサポートした Adrian White (リサーチ & テクニカルコンピューティング、APAC) は「GT-Scan2 はゲノムを小さいブロックに分けて Lambada の仕様に合わせられるようにします」と述べています。一般的に GT-Scan2 は 500-1000 件の Lambda 関数をアクティブ化し、同時に DynamoDB にある推定上の異なるターゲットスコアも更新するようになっています。このプロセスの実行中にフロントエンドは API Gateway 経由でこのテーブルをポーリングし、結果が入り次第ウェブページを更新、サーバー側からのコンピューティングを不要にしています。「AWS の Lambda のおかげで、医療ゲノムエンジニアリングのアプリケーションをサポートでき、今後の流れに対応できるソフトウェアパッケージ開発に優れたフレームワークを使用することができました」と Dr. Bauer は語っています。「特に様々なジャンルの複雑な面に対応するために、さらに多くの Lambda 関数をランタイムで瞬時に起動しスケールできる点に感心しています。」Dr. Bauer は、使用期間のみのストレージ料金を支払うことや、ウェブサイトは動的コンテンツを含む静的ページで Angular 2 や API Gateway を通じて更新されるためにウェブサーバーのリソースとジョブが競合しないことや、コンピュートインスタンスの維持が不要 (OS のセキュリティパッチ) なことも、その他のメリットであると述べています。「Lambda が優れいているポイントの 1 つは、ユーザーが特定の CRISPR アプリケーションに適した別の機械学習アルゴリズムに簡単に切り替えられることです」と Dr. Wilson は述べています。

GT-Scan2 チーム – Denis Bauer、Laurence Wilson、Aidan O’Brien (左から)

「コンピュテーショナルゲノムエンジニアリングコミュニティは AWS Lambda テクノロジーを早期に導入したコミュニティの 1 つです」と Dr. Mia Champion (Scientific Computing テクニカルビジネス開発マネージャー) は言います。「GT-Scan2 が APCI Gateway や DynamoDB を使用することは、スケーラビリティを確保する上ですばらしいソリューションと言えます。エピジェネティクスをうまく使う方法も、CRISPR 検索を実施するために Lambda を使用する最近の他のアプリケーションとは一線を画しているポイントだと思います。医療アプリケーションで GT-Scan2 が導入されていくことを楽しみにしています。」

MLB Statcast – David Ortiz、Joe Torre、Dave O’Brien をご紹介

私の同僚に十代の頃からボストンの野球チーム、レッドソックスの大ファンだという人がいます。その彼女が、つい先日レッドソックスの偉大な選手でありハンクアーロン賞も受賞した David Ortiz (別名 “ビッグパピ”) と、殿堂入りした Joe Torre、アナウンサーの Dave O’Brien (ESPN および NESN) と共に、ビッグパピのメジャーリーグ引退を記念した面白いビデオ制作に携わりました。ご覧のようにビッグパピがクオンティファイドセルフをシリアスに受け止め、引退後も競争力が衰えないように AWS を使用した Statcast でさまざまなことを測定しています。

MLB Statcast は高解像度カメラとレーダー装置を使用してボール (20,000 メトリックス/秒) と選手たち (30 メトリックス/秒) の位置をトラックし、1 試合ごとに 7 テラバイトのデータを生成します。そして、これをすべて保存し処理しているのが AWS Cloud です。このアプリケーションは Amazon CloudFrontAmazon DynamoDBAmazon Elastic Compute Cloud (EC2)Amazon ElastiCacheAmazon Simple Storage Service (S3)AWS Direct ConnectAWS Lambda など複数の AWS サービスを使用しています。アーキテクチャの全体像は次のとおりです。

詳細はこちらのケーススタディ Major League Baseball Fields Big Data, and Excitement, with AWS をご覧ください。

AWS re:Invent に参加される方は、肩を十分にほぐしてから Statcast 装置万端のバッティングケージにぜひお越しください。メジャーリーグの選手たちと自分の測定比較をすることもできます。

Jeff;

AWS 予算の更新 – クラウドのコストと使用量

スパイダーマンをはじめアクションヒーローは昔から「大いなる力には、大いなる責任が伴う」と言っています。オンデマンドで従量制のクラウドの世界では、ユーザー自身が確かな情報を備え、責任を持った顧客でなければいけないという意味として、このメッセージを捉えることができると思います。同様に企業環境においては予算と支出に注意する必要があり、実際の支出を予想額の範囲内に抑えなければなりません。そして複数のプロジェクトや部署で AWS を使用していると、こうした点を正確に追跡したり財務予測を立てることが複雑になっていきます。

そこで、この度 AWS の予算機能に重要な更新をいくつか追加しました (詳細は「AWS の新しい予算と予測」をご覧ください)。この機能はファイナンスマネージャー、プロジェクトマネージャー、DevOps のバイスプレジデント達が使用できるように設計されています (ご自分がクラウド予算の担当者でない場合は、適切な人物にこのブログを参考資料としてお知らせするのも良いでしょう)。AWS 予算を使用すれば特定のカテゴリにかかるコストや使用量を統一して見ることができます。また、自動通知を利用してステータスの詳細情報 (予算の上回りまたは下回り) を把握することができるので、潜在的な問題を識別し予算超過を防ぐための対策を講じることもできます。
AWS 予算の更新
1 つの支払いアカウントにつき 20,000 件までの予算を作成することができます。コストやリソースの消費量が頻繁に変わる環境で支出をうまく管理するため、予算は 1 日 4 回にわたり評価されるようになっています。通知はメールまたはプログラム (Amazon Simple Notification Service (SNS) メッセージ) で配信されるので、手動や半自動または完全自動の方法で状況に対応できます。これにより、次の状況や社内で発生する他の問題に取り組むことができます。

VP (バイスプレジデント) – 事業単位の予算や企業全体の予算を組み、リージョン別またはその他のカテゴリ別に支出を管理し実際の使用量と予算を比較することで、クラウド全体の支出を最適化できます。プロジェクトマネージャー – 部署内のコスト管理、複数のサービスやタグそしてリージョンを監視することができます。しきい値が超えると関係者にその旨を通知し対応を促します。必要であれば各チームメンバーにリソース予算を提供しそれを考慮して実行するように勧めることも可能です。

ファイナンスマネージャー – 自社のこれまでのコストを分析し、その情報を利用して今後の適切な予算を組むことができます。企業全体または各アカウントや各サービス、事業単位、プロジェクトチーム別にコストを見直すことができます。

予算を組む
では 1 つか 2 つ予算を作成してみましょう!

[Billing and Cost Management] を開きます。

[Budgets] をクリックします。

AWS 予算を初めて使用する場合は [Create budget] をクリックしてから次のステップに進む前に 24 時間待たなければならない場合もあります。その間、お客様の最初の詳細な請求レポートを準備します。

[Create budget] をクリックしてコストまたは使用率のどちらをベースに予算を組むのか決定してから、予算名を指定します。次に月々、3 か月、年間のいずれかを選択します。この例ではコストベース (1000 USD)/月を選択し、予算名を「MainBudget」にしました。

[Include costs related to] のオプションをチェックしなければ、この予算がアカウント全体に適用されます。チェックマークを付けると、より多くの柔軟性を提供するさまざまな追加オプションが出てきます。[Owner] タグを [jbarr:] に設定します。

これ以上に細かく設定してリザーブドインスタンス以外の使用量には少ない予算を設定することもできます。自社が所有するリザーブドインスタンスをしっかり活用するには優れた方法です。

次にメールまたはプログラムを使用した通知方法を設定します。

プログラムを使用した通知オプションはさまざまな方法で利用することができます。固定予算を指定した新しいウェブアプリを作成して、予算の上限に近付いた場合は AWS Lambda 関数を呼び出すこともできます。アプリを使用して予算超過にならないように対策を講じることもできます。また、より大量な計算を必要とする機能をいくつか一時的に無効にしたり、静的にホストする別のサイトに切り替えることができます。

目的どおりに設定したら [Create] をクリックします。すぐに予算が表示されます (このスクリーンショットを撮る前に、先に黒い三角をクリックして詳細を表示しています)。

ご覧のようにすでに 1000 USD も予算を超えています。約 5,600 USD の予算超過が予測されています。Amazon は倹約的な企業なので (詳細は「リーダシップの原則」をご覧ください)、これを詳しく調べて余分なインスタンスを取り除く必要があるのが分かりました。メール通知を受信するように設定しているので、予算を作成した後に次の通知が届きました。

データ転送の予算がコンピューティング予算と別であるとした場合、その時のコストに関係なく S3 から毎月 100 GB のデータを転送することができます。次のような予算を作成できます。

データ転送の予算を超過しないことがすぐに分かります。

さらに画面の情報を CSV 形式でダウンロードしてより詳しく調べたり、予算プロセスの別の箇所に有益な情報を得ることができます。

ご覧のように、この新機能は細かな予算設定を可能にします。今回は AWS Management Console を使用してこの機能をご紹介しましたが、新しい Budget API または AWS Command Line Interface (CLI) を呼び出して予算を設定することもできます。この API には CreateBudget, DescribeBudget、および UpdateBudget などを独自のアプリケーション内で使用することができます。今すぐ利用可能
この機能は今すぐ使い始めることができます。1 つのアカウントごとに無料で 2 つの予算を作成することができます。追加予算の費用は 0.02 USD/日です (1 アカウントにつき 20,000 件までの予算を作成できます)。詳細は「予算によるコストの管理」をご覧ください。

Jeff;

Atlassian JIRA ソフトウェアと Bitbucket データセンターの新しい AWS クイックスタート

AWS クイックスタートは AWS Cloud 内のソフトウェアソリューションのリファレンス実装を迅速にデプロイする場合に役立ちます。クイックスタートを使用すれば、AWS やソフトウェアパートナーが推奨しているベストプラクティスのメリットを活用しながら簡単にソフトウェアをテストしたり使用することができます。

今回は APN アドバンスドテクノロジーパートナー (および DevOps コンピテンシー所有者) である Atlassian と協力して開発したクイックスタートガイドのペアについてご紹介します。このクイックスタートガイドは JIRA ソフトウェアデータセンターAWS 上の Bitbucket データセンターのデプロイで役立ちます。

Atlassian のデータセンターの機能は、規模の大きな開発チームを持ち、スケーラブルで可用性の高い開発ツールとプロジェクト管理ツールを必要とするお客様のために設計されています。こうしたツールは常にミッションクリティカルであるため、堅牢性と耐障害性がベースライン要件であり、実稼働デプロイメントは常にマルチノードまたはクラスター設定で実行されるようになっています。

新しいクイックスタート
JIRA ソフトウェアデータセンターはスピードを必要とするチームにプロジェクト管理ソリューションと問題管理ソリューションを提供、Bitbucket データセンターは Git リポジトリソリューションを提供します。どちらのソリューションも、複数のプロジェクトに携わる規模の大きなチームで可用性が高く大規模なパフォーマンスを実現します。こうした新しい Atlassian クイックスタートにより、徹底的なテストとリファレンスアーキテクチャの完全サポートを利用することができるので、AWS で行う製品のデプロイを大幅に簡略化し加速することが可能になりました。

クイックスタートには、新規または既存の Virtual Private Cloud (VPC) で Bitbucket と JIRA ソフトウェアのデプロイを許可する AWS CloudFormation テンプレートが含まれています。新しい VPC を使用したい場合は、テンプレートが作成できます。同時にパブリックサブネット、プライベートサブネット、NAT ゲートウェイも作成するので、プライベートサブネットで EC2 インスタンスを許可しインターネットに接続することができます (NAT ゲートウェイを利用できないリージョンでは、代わりに NAT インスタンスをテンプレートが作成します)。すでに AWS をご利用されていて適切な VPC がある場合は、代わりに JIRA ソフトウェアデータセンターと Bitbucket データセンターをデプロイすることができます。

起動したい Atlassian 製品の評価版ラインセンスにサインアップしてください。

Bitbucket データセンター
Bitbucket データセンタークイックスタートはデプロイの一部として次のコンポーネントを実行します。

Amazon RDS PostgreSQL – Bitbucket データセンターはサポート対象になっているデータベースを必要とします。マルチ AZ 設定の Amazon RDS for PostgreSQL はマスターノードが失敗した場合にフェイルオーバーを許可します。

NFS サーバー – Bitbucket データセンターは共有ファイルシステムを使用して、複数の Bitbucket ノードがアクセスできる一般的な場所にリポジトリを保存します。クイックスタートアーキテクチャはアタッチしている Amazon Elastic Block Store (EBS) ボリュームを使用した EC2 インスタンスで共有ファイルシステムを実装します。

Bitbucket Auto Scaling グループ – Bitbucket データセンター製品は Auto Scaling グループの Amazon Elastic Compute Cloud (EC2) インスタンスにインストールされています。デプロイのスケールアウト/インは使用率により異なります。

Amazon Elasticsearch Service – Bitbucket データセンターはインデックス作成と検索に Elasticsearch を使用します。クイックスタートアーキテクチャは Amazon Elasticsearch Service を使用します。これは AWS クラウドの Elasticsearch でデプロイ、操作、スケールを行いやすくするマネージドサービスです。

JIRA ソフトウェアデータセンター
JIRA ソフトウェアデータセンタークイックスタートはデプロイの一部として次のコンポーネントを実行します。

Amazon RDS PostgreSQL – JIRA データセンターはサポート対象になっているデータベースを必要とします。マルチ AZ 設定の Amazon RDS for PostgreSQL はマスターノードが失敗した場合にフェイルオーバーを許可します。

Amazon Elastic File System – JIRA ソフトウェアデータセンターは共有ファイルシステムを使用して、複数の JIRA ノードがアクセスできる一般的な場所にアーティファクトを保存します。クイックスタートアーキテクチャは Amazon Elastic File System を使用する可用性の高い共有ファイルシステムを実装します。

JIRA Auto Scaling グループ – JIRA データセンター製品は Auto Scaling グループの Amazon Elastic Compute Cloud (EC2) インスタンスにインストールされています。デプロイのスケールアウト/インは使用率により異なります。

今後も Atlassian と協力し、この新しいクイックスタートの更新と改善を実現していきます。この他にも Atlassian Confluence と Atlassian JIRA サービスデスクのクイックスタートの作成にも取り組んでおり、AWS re:Invent までにはリリースしたいと考えています。

開始するには Bitbucket データセンタークイックスタートまたは JIRA ソフトウェアデータセンタークイックスタートをご覧ください。また Atlassian のクイックスタートページもご覧ください。テンプレートは今すぐご利用いただけます。ぜひご感想をお寄せください!

Jeff;

AWS Answers – AWS で不安を感じずに効率良く構築する

企業や団体が AWS Cloud に移行を決定しそのメリットを感じ始めたら、次のステップはアプリケーションを適切に構築することです。数々のお客様の様子を見て分かったのはベストプラクティス、具体的な設計パターン、既製のソリューション、高度な戦略的ガイダンスを探していることです。

そこで今日は新しい AWS Answers ページをご紹介します。

このページでは AWS アプリケーションのアーキテクチャや構築そして実行に関するよくある質問について分かりやすくお答えします。これにはアカウント設定インフラストラクチャ管理、ログ移行モバイルアプリケーションネットワーキングセキュリティウェブアプリケーションなどがあり、項目別にそれぞれのガイダンスを提供しています。経験豊富な AWS アーキテクトが情報を提供し、回答は Q&A 形式で掲載します。回答に協力したスタッフ全員がお客様と直接コミュニケーションを取り、プロセス時に集積した実際の経験をどの回答にも反映させています。

各回答は、ポイントを押さえて説明したブリーフィングまたは AWS CloudFormation を使用してデプロイできる自動化ソリューション、オンラインで閲覧可能もしくは PDF 形式でダウンロードできる実装ガイドなど、どの質問においても具体的な解決方法を提供しています。回答例は次をご覧ください。

AWS WAF を使用して構成済みの保護をデプロイするには? – 右側の図のように、構成済みの AWS WAF ルールとカスタムコンポーネント (honeypot を含む) をソリューションが設定します。
Amazon EC2 インスタンスを自動的に開始または停止するには? – 使用していない EC2 インスタンスを停止し必要に応じて再開するには、ソリューションが EC2 スケジューラを設定します。

Amazon Machine Image に含むべきものは? このブリーフィングではイメージ作成のベストプラクティスと一般的な 3 つの AMI 設計について紹介しています。

AWS で VPN モニタリングを導入するには? – ソリューションは VPN モニタリングをデプロイし、カスタムの CloudWatch メトリックスとして履歴データを自動記録します。

単一の VPN 接続を多重 VPC と共有するには? このブリーフィングは複数の Amazon VPC ネットワークとオンプレミスインフラストラクチャ間のリモート接続数を最小限に抑える方法を説明しています。

Jeff;