Category: Containers

2020 年 5 月、AWS は NVIDIA Clara Train アプリケーションフレームワークを使った医療画像モデルの開発環境を AWS クラウドにデプロイするために使用できる AWS クイックスタートをリリースしました。Philips および Cerner などの多数のヘルスケアおよびライフサイエンス関連のお客様が、機密性の高いヘルスケアワークロードに関して AWS を信頼しておられます。セキュアでスケーラブルなクラウドインフラストラクチャは、データサイエンティスト、アーキテクト、および医療研究者が、医療コミュニティを支援するための機械学習 (ML) のワークフローとパイプラインの構築に集中できるようにします。 FDA に認可された AI は、すでに世界中の病院で医師たちが時宜を得た高品質のケアを提供するために役立っています。商用ソリューションには AWS で本番環境の医療画像ワークロードを確立しているものがあり、これには GE ヘルスケア、Zebra、Arterys、および Heartflow によって開発されたソリューションが含まれます。これらの成功にもかかわらず、ヘルスケアにおける革命はまだ初期の段階にあり、データと ML のパイプラインが臨床医による診断、ワークフローの最適化、医療機器の強化、および臨床品質の向上を補助する機会が今後ますます増えるでしょう。 以下のセクションでは、NVIDIA Clara Train アプリケーションフレームワークを紹介してから、CT スキャンにおける脾臓のセマンティックセグメンテーションに関する実際のユースケースに対応するためのデプロイメントについて説明します。このクイックスタートは、Amazon Elastic Container Service (ECS) と、NVIDIA V100 Tensor Core GPU 搭載の Amazon EC2 p3.2xlarge インスタンスタイプを使って Clara Train SDK をデプロイします。 […]

この記事は Yuling Zhou、Eduardo Lopez Biagi、Paavan Mistry の執筆によります 本日は、AWS Fargate プラットフォームバージョン 1.4 での、一時的なストレージにおけるサーバー側の暗号化を紹介します。この更新版のプラットフォームバージョンでは、AWS Fargate が管理するキーと業界標準の AES-256 暗号化アルゴリズムを使って、一時的なタスクストレージが自動的に暗号化されます。お客様がプラットフォームバージョン 1.4 で新たに起動する Amazon ECS タスクやサービスは、特別な設定を必要とせずにこの機能をご利用になれます。AWS Fargate 上で起動する Amazon EKS ポッドにはプラットフォームバージョン 1.4 が使用されます。したがって本日以降に起動されるポッドでは、一時的なストレージが Fargate 管理のキーにより暗号化されるようになります。 AWS Fargate でサービスを構築しているお客様には、保存中のデータに対する暗号化の需要があります。この場合、アプリケーションやワークロードもしくは環境に対応して、特定の機密やセキュリティおよびコンプライアンス上の要件を満たす必要があります。保存データの暗号化は、ディスク上に保存された機密性のあるデータを、不正アクセスから確実に保護するための法的コンプライアンスにとって非常に重要です。PCI DSS や HIPAA など一部のコンプライアンス規制では、保存されているデータには、そのライフサイクル全体を通じての暗号化が求められます。当社では昨年、AWS Fargate の一時的ストレージに保存したデータに対する暗号化に関し、お客様からのご提案を集める目的で、AWS containers roadmap の #314 版を通じてフィードバックを求めました。 従来、タスクストレージに書き込まれたデータの暗号化において、AWS Fargate のお客様が組織上のセキュリティとコンプライアンス要件を満たすためには、データ暗号化の制御機能を設計し、それをアプリケーションアーキテクチャの中に実装する必要がありました。今回の新機能では、データ保存中の一時的なタスクストレージが Fargate 管理のキーを用い暗号化されるので、お客様は、組織内もしくは法規制上のセキュリティとコンプライアンス要件を満たすことが可能になります。この機能を使うことで、AWS Fargate のタスクやサービスにアタッチされた一時的なストレージに書き込まれるデータは、お客様が一切のアクションを起こす必要もなく、そのストレージ上で常に暗号化され保存されるようになります。これにより、AWS Fargate で実行するタスクを綿密に保護するための、新たなセキュリティ層が追加されます。 AWS Fargate […]

 この記事は、Sri Mallu、Re Alvarez-Parmar、Sahil Thapar が寄稿したものです Application Load Balancer は、高可用、スケーラブルで安全なアプリケーションを構築する際、重要な要素となっています。AWS のお客様は、ALB を利用することで、従来からアプリケーションのコードで使えた機能を実行できます。接続のセキュリティを例にとると、ALB を使用して暗号化と復号化の作業をオフロードできるため、アプリケーションのビジネスロジックに集中できます。 Application Load Balancer を使用すると、暗号化された接続 (SSL オフロードとも呼ばれる) を使用する HTTPS リスナーを作成できます。この機能により、ロードバランサーと、SSL または TLS セッションを開始するクライアント間のトラフィックの暗号化が可能になります。HTTPS リスナーを作成するときは、SSL/TLS サーバー証明書をロードバランサーにデプロイします。ロードバランサーは、このサーバー証明書を使用してフロントエンド接続を終了し、クライアントからのリクエストを復号化してからターゲットに送信します。ALB がリクエストを復号化する必要があるのはなぜでしょうか? ALB がリクエストを復号化する必要があるのは、それが Open Systems Interconnection (OSI) モデルのアプリケーション層で動作していて、リクエストをルーティングするにはリクエストを検査する必要があるためです。リクエストをルーティングするには、HTTP ヘッダー、メソッド、クエリパラメータ、ソース IP CIDR に基づいて ALB を使用できます。ALB を使用してアプリケーションの負荷を分散すると、ALB で SSL/TLS が終了するのはそのためで、通常、ALB とバックエンドアプリケーション間の接続は暗号化されません。ロードバランサーで安全な接続を終了し、バックエンドで HTTP を使用するだけで、お使いのアプリケーションにとっては十分かもしれません。AWS リソース間のネットワークトラフィックは、接続の一部であるインスタンスのみがリッスンできるからです。 ただし、厳しい外部規制に準拠する必要があるアプリケーションを開発している場合は、すべてのネットワーク接続を保護する必要があることがあります。 以下、クライアントとロードバランサーの間、およびロードバランサーから ECS クラスターで実行されているアプリケーションコンテナへの接続を暗号化する方法を示します。この記事では、Fargate の ECS […]

 AWS は、コンテナ化されたアプリケーションを実行するための最良の選択肢を提供しています。Amazon Elastic Container Service (ECS) のリリースにより、AWS と深く統合されたフルマネージドの Docker 体験で、コンテナを大規模にデプロイできるようになりました。また、マネージド Kubernetes を提供する Amazon Elastic Kubernetes Service (EKS)、AWS Fargate のリリースにより、インフラストラクチャを管理せずにコンテナの実行ができるようになりました。私たちはお客様のためにこれからも革新を続けていきます。 Red Hat OpenShift を使用して AWS でコンテナを実行するお客様も多く、OpenShift をデプロイするにあたり AWS マネージドサービスで得られるセキュリティ、スケーラビリティ、信頼性を利用したいという声が頻繁に寄せられています。2008 年以降、Red Hat と AWS のコラボレーションにより AWS で簡単に Red Hat Enterprise Linux を実行できるようになりました。私たちはさらにコラボレーションを拡大し、今年の後半には新たにマネージド Red Hat OpenShift サービスをリリースする予定です。この新サービスでは、クラスターの作成と運用、AWS のサービスとのより深い統合、オンデマンド (1 時間単位) の請求、AWS を介した単一の請求書、AWS へのサポート問い合わせが、セルフサービスで利用可能です。この新しいマネージド Red Hat OpenShift サービスにより、AWS […]

 Amazon Elastic Container Service (ECS) と Amazon Elastic File System (EFS) のネイティブ統合が最近導入されました。Amazon ECS は、クラウド専用に構築され、他の AWS のサービスと統合されたフルマネージド型のコンテナオーケストレーターサービスです。ECS は、Amazon EC2 と AWS Fargate の両方で、(いわゆるタスクにラップされる) コンテナのデプロイをサポートしています。Amazon EFS は、ECS や EC2 インスタンスなどの他の AWS のサービスで使用するように設計された、フルマネージド型の柔軟な共有ファイルシステムです。Amazon EFS は透過的にスケーリングし、データをレプリケートし、アベイラビリティーゾーン全体で利用できるようにし、複数のストレージ階層をサポートしています。これにより、大部分のワークロードの要求に対応しています。 この統合は、EC2 インスタンスまたは Fargate を使用するすべての ECS のお客様がご活用いただけます。この統合は、Fargate の、AWS が最近リリースしたプラットフォームバージョン 1.4 で有効になりました。 開始する前に、この統合はオーケストレーター固有であることをはっきりさせておくことが重要です。これは、ECS on EC2 と ECS on Fargate の両方に適用される Amazon ECS タスクレベルの設定だからです。Amazon EKS […]

 Amazon EFS を Amazon ECS と AWS Fargate で使用する方法に関するこのブログ記事シリーズのパート 3 へようこそ。参考までに、このブログ記事シリーズは次のように構成されています。 パート 1: このブログ記事は、この統合の必要性とその範囲に関する背景情報を提供し、この機能により道が開かれ、お客様に役立つユースケースとシナリオの概要を示します パート 2: ECS と Fargate に基づきコンテナをデプロイする際の EFS のセキュリティの仕組みの詳細と、リージョンごとの ECS と EFS のデプロイのベストプラクティスに関する高レベルの考慮事項を扱います パート 3: [このブログ記事] コンテナ化されたアプリケーションの再利用可能なコードとコマンドを含む実用的な例を紹介します。アプリケーションは EFS を使用した ECS タスクにデプロイされたものです この記事では、パート 1 とパート 2 で学んだことを試すためのサンプルコードを作成します。このブログを 2 つのメインブロックに分割します (2 つの個別の例を使用して)。その 2 つは以下のとおりです。 ファイルシステムの永続性を必要とするアプリケーションを実行するためのスタンドアロンのステートフルタスク 共有ファイルシステムに並行して複数のタスクにアクセスする これらの背後にある理論について詳しく知りたい場合は、パート 1 をご覧ください。次に、サンプルコードについて詳しく説明します。 これらの例では、ECS タスクは Fargate で実行されますが、EC2 […]

Amazon EFS を Amazon ECS と AWS Fargate で使用する方法に関するこのブログ記事シリーズのパート 2 へようこそ。参考までに、このブログ記事シリーズは次のように構成されています。 パート 1: このブログ記事は、この統合の必要性とその範囲に関する背景情報を提供し、この機能により道が開かれ、お客様に役立つユースケースとシナリオの概要を示します パート 2: [このブログ記事] ECS と Fargate に基づきコンテナをデプロイする際の EFS のセキュリティの仕組みの詳細と、リージョンごとの ECS と EFS のデプロイのベストプラクティスに関する高レベルの考慮事項を扱います パート 3: コンテナ化されたアプリケーションの再利用可能なコードとコマンドを含む実用的な例を紹介します。アプリケーションは EFS を使用した ECS タスクにデプロイされたものです このブログ記事は、Amazon ECS と AWS Fargate を使用している開発者で、Amazon EFS との統合を使用して、各リージョンで弾力性があり、スケーラブルなステートフルサービスをデプロイする方法を学びたい方を対象としています。 パート 3 は、このすべての理論を実践するパートです! 可用性、コスト、拡張性のための Amazon ECS と AWS Fargate アーキテクチャ Amazon ECS は、リージョン別に分散されたコンテナオーケストレーターで、AWS […]

 コンテナは、クラウドアプリケーションの開発とデプロイにおける事実上の標準です。コンテナイメージでソフトウェアを公開すると、統合パッケージソリューション、バンドルソフトウェア、および必要なすべての依存関係をポータブルイメージ形式で開発者に提供します。このイメージはどこでも実行でき、デプロイメントにおけるインフラストラクチャ固有の側面を抽象化します。 ただし、どこでも実行できるということはお約束できます。一部のアプリケーションには、Linux と Windows の両方のサポートなど、特定のホストプラットフォームまたはオペレーティングシステムの要件があります。コンピューティングアーキテクチャは、別の変数です。特に EC2 で実行されている AWS Graviton ARM ベースのインスタンスで、その比率は優れた料金対パフォーマンスを備えています。今日まで、このようなコンテナイメージは、アーキテクチャ固有の命名規則を使用して Amazon ECR に公開およびデプロイする必要がありました。そのため、イメージライフサイクルの一部側面が複雑になりました。 本日、Amazon ECR のマルチアーキテクチャコンテナイメージを発表いたします。これは待望していた機能であり、同じイメージリポジトリから異なるアーキテクチャやオペレーティングシステムのコンテナイメージを簡単にデプロイできます。 内部のコンテナイメージ Amazon ECR は完全マネージド型のコンテナレジストリで、開発者はコンテナイメージを簡単に保存、管理、およびデプロイできます。高可用性かつスケーラブルで、簡単に使用できます。マルチアーキテクチャイメージの詳細を説明する前に、コンテナイメージ機能の基本的な側面について説明します。 「コンテナ」という用語は、プロセスを実行する分離済みコンピューティング環境を提供するための一連のオペレーティングシステムコンポーネント、コンピューティングリソース、および構成を指します。コンテナに指定されたリソースの 1 つが、そのファイルシステムです。コンテナイメージを参照する場合、このポータブル形式のファイルシステムと、参照するコンテナ構成およびその他のメタデータをご覧ください。Docker などの一般的なコンテナ開発ツールを使用すれば、開発者はソフトウェアまたはサービスと必要なすべての依存関係を含むコンテナイメージを作成できます。これにより、コンテナがポータブルなオプションになります。 コンテナイメージは、レイヤーとマニフェストといった 2 つのメイン部分で構成されます。各コンテナイメージには、ファイルシステムコンテンツの 1 つ以上のレイヤーがあります。マニフェストは、イメージを構成するレイヤー、およびそのランタイムの特性と構成を指定します。Docker のコンテナイメージ形式は、Docker イメージ仕様と関連するイメージマニフェスト仕様で定義されています。Open Containers Initiative は、ランタイムにとらわれない OCI イメージ仕様を定義しました。 Amazon ECR のようなイメージレジストリは、これらの仕様に準拠したイメージをリポジトリに格納し、特定の各イメージは 1 つ以上のタグによって参照されます。イメージは通常、イメージをプッシュおよびプルするときにソフトウェアやサービスのバージョンを指定する目的でタグ付けされます。これらすべてをまとめると、最初に Docker または別のコンテナランタイムで使用するコンテナイメージをプルしたとき、2 つの事像が起こります。最初に、指定されたイメージリポジトリとタグに基づいてマニフェストがローカルにプルされ、次に指定されたレイヤーからコンテナファイルシステムを組み立てるためにマニフェストが使用されます。 具体的な例として、docker inspect <image> コマンドを使用して、Docker 開発環境のローカルイメージのマニフェストを確認できます。ご覧のとおり、アーキテクチャやオペレーティングシステムなどのプラットフォーム特性は、イメージマニフェストによって明確に指定されています。では、さまざまなオペレーティングシステムやプラットフォームアーキテクチャに簡単にコンテナをデプロイするにはどうすればよいでしょうか。 今日まで、Amazon ECR のリポジトリにイメージを公開するとき、これらの特性をイメージタグで指定する必要がありました。または、同じソースからビルドされたプラットフォーム固有のイメージを独自のイメージリポジトリに保存することもできます。次に、コンピューティング環境に適したバージョンのイメージを明示的に参照して取得する必要があります。例: {aws-account-id}.dkr.ecr.{aws-region}.amazonaws.com/my-image-linux-arm64:2.7 […]

Apache Spark はオープンソースプロジェクトで、分析分野で幅広い人気を博しています。有名なビッグデータや、ストリーミングといったの機械学習ワークロード、幅広いデータセットの処理、ETL などで使用されています。 Kubernetes は、人気のあるオープンソースのコンテナ管理システムで、アプリケーションのデプロイ、メンテナンス、スケーリングのための基本的なメカニズムを提供します。Amazon EKS は、高可用性コントロールプレーンを提供するマネージド Kubernetes サービスで、AWS で本番環境レベルのワークロードを実行します。お客様は、EKS でマイクロサービス、バッチ、機械学習などのさまざまなワークロードを実行できます。 このブログは、Kubernetes で Spark ワークロードをプラットフォームとして実行することを好むエンジニアやデータサイエンティスト向けです。 Kubernetes で Spark を実行することを検討すべき理由 お客様が Kubernetes での Spark の実行を検討する理由を説明します。 Kubernetes は Spark リソースマネージャーのネイティブオプションです Spark 2.3 以降では、Kubernetes を使用して Spark リソースを実行および管理できます。それ以前は、Hadoop Yarn、Apache Mesos を使用して Spark を実行するか、スタンドアロンクラスターで実行できました。Kubernetes で Spark を実行すると、実験にかかる時間が短くなります。さらに、最小限の複雑さでさまざまな最適化手法を使用できます。 コンテナと Kubernetes エコシステムで実行する利点 Spark アプリケーションをコンテナとしてパッケージ化することで、アプリケーションと一緒に依存関係を単一のエンティティとしてパッケージ化できるため、コンテナのメリットを享受できます。Hadoop バージョンとの互換性に関するライブラリバージョンの不一致に関する懸念がありますが、コンテナを使用することで維持が容易になります。もう 1 つの利点は、バージョン管理を行い、タグをコンテナイメージに適用できることです。このようにして、異なるバージョンの Spark またはその依存関係を使用して実験する必要がある場合に、そうすることが容易になります。 スタックで Kubernetes […]

 はじめに 機械学習チームが Kubernetes を使用すると、Amazon EC2 P3 などの強力な GPU インスタンスのフリート全体に分散したトレーニングジョブを実行でき、トレーニング時間を数日から数時間に短縮することができます。しかし、Kubernetes によく関連付けられている従来のマイクロサービスベースのアプリケーションと比較すると、分散トレーニングには制限があります。分散トレーニングジョブは耐障害性がありませんし、ノードの障害または回復によってトレーニングが中断された場合、ジョブを続行できません。それに加え、要求されたリソースをすべて取得しないとジョブを開始できず、また、再起動せずに拡張や縮小することもできません。このように、回復性と柔軟性が欠如しているため、トレーニングの時間とコストが増大します。 この投稿では、AWS の Kubernetes チームと Facebook の PyTorch チーム間の新しいオープンソースコラボレーションである TorchElastic Controller for Kubernetesについて説明します。これで、上記のような制限に対処したり、PyTorch ビルドモデルや Kubernetes 分散トレーニングの新機能を利用できます。たとえば、EC2 スポットインスタンスでのトレーニング、ハードウェア障害に耐性のあるジョブの実行、クラスターリソースの可用性に基づいた動的なジョブのスケーリングなどが可能となります。 PyTorch Elastic と Kubernetes の統合 PyTorch Elastic は大規模な深層学習モデルをトレーニングするためのライブラリで、動的な可用性に基づいたコンピューティングリソースのスケーリングに不可欠です。PyTorch ジョブを作成するためのプリミティブとインターフェースで、複数のマシンで伸縮性を持ちつつ実行できるようになります。最小限のワーカーが集まるとすぐに分散ジョブを開始でき、停止または再起動を実行しなくても最大数のワーカーまで拡張できます。伸縮性とは、トレーニングジョブ中にフレームワークがノード数を拡張または縮小する機能です。耐障害性とは、ジョブを再起動せずに、フレームワークがトレーニングジョブ中に失敗したノードを検出して置き換えることができる機能です。 PyTorch Elastic には Rendezvous と呼ばれるコンポーネントが含まれています。このコンポーネントはトレーニングジョブの参加者 (ワーカー) を集め、そこで、全員が参加者と全員のロールとの同じリストに同意し、トレーニングをいつ開始/再開できるかについて一貫した集団での決定を行います。詳細については、GitHub のオープンソースプロジェクトにアクセスしてください。 TorchElastic Controller for Kubernetes (TECK) は PyTorch Elastic インターフェースのネイティブ Kubernetes 実装で、TorchElastic […]