Category: Containers

 この記事は、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 […]

2020 年 3 月 10 日、Linux コンテナをホストするために設計された新しい特定目的オペレーティングシステムである Bottlerocket を導入しました。この記事では、当社が掲げたいくつかの目標、その過程で行ったエンジニアリングの選択、OS が今後も進化し続けるというビジョンについて説明します。 2014 年に、Linux コンテナのオーケストレーションサービスである Amazon Elastic Container Service (ECS) を開始しました。サービスとともに、事前設定済みでコンテナをホストするためにすぐに使用できるオペレーティングシステム、Amazon ECS に最適化された AMI を立ち上げました。この AMI は、ECS 向けに 2 つの方法で最適化されました。まず、ECS で Docker コンテナを実行するために必要なすべてのソフトウェアがインストールされており、起動するとすぐに準備が整います。そして 2 つ目は、Amazon Linux AMI のやや簡略化されたバージョンに基づいており、維持する必要のある不要なソフトウェアを削減し、ディスク領域を節約することを目的としています。ただし、この AMI は依然として、コンテナの外で従来のソフトウェアアプリケーションを実行するために設計された汎用オペレーティングシステムに基づいていました。 2017 年に Amazon Elastic Kubernetes Service (EKS) を立ち上げたとき、当社は同じことを行いました。Kubernetes ポッドをホストするための事前設定済みですぐに使用できるオペレーティングシステムとして、Amazon EKS に最適化された AMI がそれです。Amazon ECS に最適化された AMI と同様に、Amazon […]

Amazon EKS を使用する場合、すべてのノードは、EKS がホストする Kubernetes クラスターと、Amazon Elastic Container Registry (ECR) や Amazon S3 などの他の AWS API に接続できる必要があります。ノードはプライベートサブネットまたはパブリックサブネットで実行できます。プライベートサブネットの場合、このトラフィックは通常、AWS PrivateLink 接続を経由して、VPC または NAT ゲートウェイ内のエンドポイントに到達し、VPC の外部のエンドポイントに到達します。パブリックサブネットの場合、VPC の外部の API エンドポイントに到達するには、ノードにパブリック IP が割り当てられている必要があります。 現在、EKS マネージドノードグループは、起動するすべてのノードにパブリック IP アドレスを自動的に割り当てます。EC2 インスタンスまたは起動テンプレートで AssociatePublicIpAddress フラグを使用して、パブリック IP アドレスが割り当てられると、サブネットの設定が上書きされます。つまり、VPC がパブリックサブネットとプライベートサブネットの両方、またはプライベート専用サブネットアーキテクチャで設定されている場合でも、パブリック IP は依然としてプライベートサブネットでインスタンスを作成するノードに割り当てられます。 2020 年 4 月 20 日よりマネージドノードグループの動作が更新され、パブリック IP がノードに割り当てられなくなります。この日以降、パブリック IP の割り当ては、ノードがインスタンスを作成するサブネット設定を介して制御する必要があります。 この変更は 4 月 20 日以降に作成した新しいマネージドノードグループにのみ影響し、既存のマネージドノードグループの動作には変更はありません。 […]