Amazon Web Services ブログ

Category: Containers

Bottlerocket: 特定目的のコンテナオペレーティングシステム

 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 […]

Read More

EKS マネージドノードグループの IP 割り当てに対する今後の変更

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 日以降に作成した新しいマネージドノードグループにのみ影響し、既存のマネージドノードグループの動作には変更はありません。 […]

Read More

Amazon EKS クラスター向けのマルチテナント設計時の考慮事項

この投稿は、AWS ソリューションアーキテクトの Roberto Migli による寄稿です。 Amazon Elastic Kubernetes Service (Amazon EKS) は、今日、コンテナアプリケーションを大規模に実行するために、数千の顧客が使用しています。よくある質問の中でも、マルチテナントの Amazon EKS クラスターをチームに提供することについてよく耳にします。 1 つまたは多くのクラスターを実行する必要がありますか? チームごと、環境ごと、アカウントごとに 1 つのクラスターを使用する必要がありますか? 正解や不正解はありません。この投稿では、正しい判断を下すためにいくつかの側面を検討していきます。 問題 マルチテナンシーでは、異なるワークロードまたはチームが同じクラスターを共有し、それらをある程度、論理的または物理的に分離する必要があります。さまざまな理由から分離が必要になる場合があります。たとえば、セキュリティは、各チームが意図したワークロードでのみ動作し、他のチームのワークロードでは動作できないようにするか、アプリケーション間でネットワークを分離 (デフォルトでは、すべての名前空間内のすべてのポッドが相互通信できる) します。もう 1 つの理由は、同じインフラストラクチャを共有するさまざまなワークロード全体でリソース (CPU、メモリ、ネットワークなど) を公平に配分するためです。顧客ごとにソリューションをデプロイするサービスのソフトウェア企業は、同じクラスター上で複数のテナントを実行することでインフラストラクチャの利用率を高めることができますが、各テナント間をさらに高度に分離する必要があります。 マルチテナンシーのための Kubernetes ネイティブソリューション Kubernetes は、1 つのクラスター内でマルチテナンシー設計に役立つネイティブの Kubernetes API と構造をいくつか提供します。コンピューティング、ネットワーキング、ストレージの主な構成要素を以下に示します。 分離を計算する Kubernetes のドキュメントは、名前空間を「複数のユーザー間でクラスターリソースを分割する方法」と定義しているため、マルチテナンシーの基礎となります。Kubernetes オブジェクトのほとんどは名前空間に属しています。下の図には 2 つの名前空間があり、それぞれが互いに実質的に分離されたオブジェクトのセットを実行しています。   名前空間はワークロードやユーザーの分離を提供しませんが、次のコンポーネントを理解するための核心です。1 つ目はロールベースのアクセスコントロール (RBAC) です。Kubernetes API で誰が何を実行できるかを定義する方法を提供します。承認は ClusterRole を介してクラスターに適用することも、Role を介して 1 […]

Read More

Amazon EKS クラスターリソースへのクロスアカウントアクセスを有効にする

この記事は、Satya Sai Naga Venkata Kumar Vajrapu と Jason Smith が寄稿しました。 Amazon Elastic Kubernetes Service (Amazon EKS) は、Kubernetes コントロールプレーンを立ち上げたり維持したりすることなく、AWS で Kubernetes を簡単に実行できるマネージドサービスです。管理対象ノードグループと AWS Fargate での Amazon EKS の最近のリリースにより、ポッド向けにインフラストラクチャをプロビジョニングおよび管理する必要がなくなりました。Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するためのオープンソースシステムです お客様は複数の AWS アカウントを使用して AWS 環境を管理していることがよくあります。そのようなお客様は、実稼働リソースが開発またはステージングリソースと対話したり共存したりすることを望んでいません。これにより、リソースの分離が向上するという利点が得られますが、アクセス管理のオーバーヘッドが増加します。 AWS Security Token Service (STS) および IAM ロールを使用して、一時的な AWS セキュリティ認証情報を活用することにより、複数のアカウントへのユーザーアクセスを管理できます。けれども、あるアカウントでホストされている Amazon EKS クラスター内のコンテナ化されたワークロードやポッドなどのリソースが、別のアカウントでホストされている Amazon EKS クラスターリソースとやり取りしたい場合はどうでしょうか? こちらの以前のブログでは、サービスアカウントの IAM ロール (IRSA) を使用して、ポッドレベルできめ細かいロールを使用する方法について説明しました。このブログでは、このソリューションを拡張し、あるアカウントでホストされている Amazon […]

Read More

Amazon API Gateway を Amazon EKS における Ingress として利用する

チームが Amazon EKS にマイクロサービスをデプロイすると、通常、フロントエンドおよびサードパーティーアプリケーションで使用する REST API を公開します。ベストプラクティスは、これらの API を API Gateway で管理することです。 これにより、API の一意のエントリポイントが提供され、各マイクロサービスのセキュリティ、キャッシュ、スロットル、監視などの API 固有のコードを実装する必要もなくなります。このパターンは、ALB Ingress Controller と Amazon API Gateway を使用して実装できます。Amazon API Gateway は、あらゆる規模でセキュアな API を管理するための完全マネージドサービスです。このアプローチは機能しますが、いくつかの構成ファイルを作成する必要があります。このタスクをどのように自動化できますか? この記事では、オープンソースソリューション API Gateway Ingress Controller の使用方法を示します。これは、Amazon API Gateway の HTTP プロキシモードを活用して Amazon EKS で実行する API をすばやく設定することで、手動手順を削減します。API Gateway Ingress Controller は、リバースプロキシポッドの前に Network Load Balancer を構成します。これは、パスベースのルーティングを処理し、HTTP リクエストをポッドにルーティングします。次の図は、この記事で説明した高レベルのアーキテクチャを示しています。 Kubernetes Ingress […]

Read More

Amazon FSx for Windows File Server を Windows コンテナの永続ストレージとして使用する

この投稿は、Marcio Morales、Sandeep Srinivas Indraganti、Alain Vetier、Pavneet Ahluwalia による寄稿です。 このブログ投稿では、Amazon Elastic Container Service (ECS) で動作中の Windows コンテナ用の永続ストレージとして、Amazon FSx for Windows File Server を使用する方法について順を追って説明します。AWS System Manager ドキュメントを使用して、コンテナインスタンス上のファイル共有マッピングを自動化し、Docker ボリュームをコンテナに提供するための ECS タスク定義を設定します。 現在、Amazon FSx File Share を介して Windows コンテナの永続ストレージを公式にサポートしています。マネージド機能は、以下で強調表示されているワークアラウンドに必要とされる差別化されていない手間がかかる作業を取り除くことを目的としています。 では、これをどのように実現するかをご説明します。 Windows Server バージョン 1709 (Windows Server 2016「半期チャネル」) で「SMB グローバルマッピング」と呼ばれる SMB プロトコルの既存の機能を活用します。SMB グローバルマッピングを使用すると、SMB 共有をホストにマウントし、その共有上のディレクトリをコンテナに渡すことができます。コンテナを特定のサーバー、共有、ユーザー名、またはパスワードで設定する必要はありません。これらはすべてホストが代わりに処理します。コンテナは、ローカルストレージがある場合と同じように機能します。 前提条件および仮定 コンピューターに AWS CLI と AWS Tools […]

Read More

AWS App Mesh と Fluent Bit でアクセスログを簡単に作成

マイクロサービスという用語は、話し相手に応じて異なる意味と利点を持ちます。しかし、私の意見と一致した利点の 1 つは、マイクロサービスにより、チームが各ジョブに最適なツールを自由に選択できるということです。つまり、マイクロサービスアーキテクチャは「サイズが 1 つでもすべてに適合する」アプローチに従う必要がありません。 このアプローチのおかげでチームは独立して作業できますが、その一方でマイクロサービスアーキテクチャの成長に伴い、いくつかの課題に直面する可能性があります。多言語マイクロサービスアーキテクチャの課題の 1 つは、さまざまなアクセスログを一元化されたログソリューションに送信する際に、一貫した形式に関連付けるということです。ログにデータの一貫性がない状態で相互作用しているさまざまなサービスで特定のエラーまたはステータスコードを見つける場合を想像してください。 さらに、そのデータをログソリューションに取り込むために必要なすべての異なるパーサーを維持しようとしていると仮定します。マイクロサービスアーキテクチャが組織にもたらすイノベーションと、市場投入までの時間を短縮できるので、サイクルを無駄にしたくないと思うでしょう。 前述の課題は、AWS App Mesh がサービスメッシュの背後でサービスを統合するのが最適である理由の 1 つにすぎません。App Mesh を使用すると、環境内のさまざまなサービス間で可視性を確保しながら、それらのサービス間の通信を簡単にモニタリング、制御、デバッグすることができます。App Mesh は Envoy をサービスメッシュにあるコンテナの前のプロキシとして活用し、一貫した形式でアクセスログを生成できます。このブログ記事では、AWS App Mesh と Fluent Bit を使用して、マイクロサービスアプリケーション用に構造化された一貫ログ形式を実装する方法を学びます。 Envoy と Envoy アクセスログについて理解する 始める前に、Envoy と App Mesh の基本を説明しましょう。前述のように、App Mesh はオープンソースの Envoy プロキシを使用しており、幅広い AWS Partner Network (APN) テクノロジーパートナーとオープンソースツールと互換性があります。これにより、複数のタイプのコンピューティングインフラストラクチャにわたって構築されたサービスの一貫した可視性とネットワークトラフィック制御を実現します。 アクセスログとそれらのログ形式に関して、Envoy プロキシはアクセスログを生成するときに形式文字列を使用します。これは HTTP リクエストの詳細を含むプレーンな文字列です。以下は、Envoy がアクセスログに使用する形式です。 [%START_TIME%] “%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%” %RESPONSE_CODE% %RESPONSE_FLAGS% […]

Read More

面白法人カヤックにおけるビルディングブロックとしてのAmazon ECSの活用とサービス間連携の工夫

開発者がアプリケーションを開発・パッケージング・デプロイするための強力な手法として、コンテナ技術はその代表的な1つに挙げられます。そしてそのようなコンテナ技術における様々なユースケースをサポートすべく、AWSではAmazon Elastic Container Service (Amazon ECS) に代表される多様なサービスを提供しています。
面白法人カヤック の技術部/インフラエンジニアである 藤原 俊一郎 氏にゲスト投稿いただき、Amazon ECS をはじめとした各AWSサービスをビルディングブロックとして組み合わせて利用していく上での課題と、その解決策の実例を紹介します。

Read More

コンテナの世界での AWS Fargate の役割

2017 年、AWS は、AWS Fargate と呼ばれる大規模なコンテナを実行するサーバーレスサービスを導入しました。今日、お客様は毎週何百万ものコンテナをローンチしています。お客様が Fargate を好むのは、多くのインフラストラクチャにまつわる未分類の重労働から解放してくれるからだと繰り返し伝え聞いています。たとえば、お客様は EC2 フリートまたはコンテナランタイムのサイズ変更、スケーリング、パッチ適用、更新について責任を負う必要がなくなりました。 過去 2 年間で気付いたのは、Fargate は非常に斬新なアイデアであることから、お客様の中には大規模な AWS コンテナポートフォリオの特定のレイヤーに入れるのが難しいと感じていらっしゃる方もおられるということです。当社は、お客様の真の問題を解決する有用なサービスの構築に余念がありません。その一方で、お客様やパートナーが当社が描く軌跡と長期的に構築しようとしているものを簡単に理解できるように当社のサービスを説明し、配置できることが重要だとも考えています。 このブログ記事では、Fargate のアーキテクチャについては詳しく説明しません。詳細よりも、Fargate の「製品」と Fargate の「テクノロジー」の違いと、それがより大きなコンテナエコシステムにどのように適合するかに焦点を当てて、全体像を描くことに紙面を割きたいと思います。AWS Fargate の主要な側面に光を当て、特にこの製品が Amazon Elastic Container Service (ECS) や Amazon Elastic Kubernetes Service (EKS) といった他のコンテナサービスとどのように関係するかを明確にしていきます。 これまでの経緯 これまでの経緯を明確に把握していないと、現在の立ち位置を把握することができません。話は遡りますが、2013 年に Docker が導入されたときに、お客様がコンテナを活用できる方法が様変わりしました。当時、その大部分を「ラップトッププレイ」が占めていました。 言い換えれば、開発者はラップトップでこの技術を活用して、個人の生産性を向上させていました。テクノロジーではさらに多くのことが行えますが、このブログ記事のコンテキストでは、パーソナルコンピューター上のコンテナを「docker run」する機能に焦点を当てます。 時間が経つにつれて、人々はこの技術の力を実感し始め、それを「ラップトッププレイ」 (個人的なテストと開発目的) から本番アプリケーションを実行するための「クラウドプレイ」に進化させました。また、それを達成するためには、単なる「docker run」を超えてラップトップで単一のコンテナを手動で起動するものが必要であることが明らかになりました。 これが、いわゆる「コンテナオーケストレーター」が形になり始めたときです。Amazon ECS は、2015 年に AWS マネージドクラウドサービスとして登場した初期のサービスの 1 つです。Kubernetes は、ほぼ同時に OSS […]

Read More

AWS ALB Ingress Controller の App Mesh への統合

AWS App Mesh は、アプリケーションレベルのネットワークを提供するサービスメッシュであり、サービスが複数のタイプのコンピューティングインフラストラクチャ間で簡単に相互通信できるようにします。App Mesh はサービスの通信方法を標準化し、エンドツーエンドの可視性を提供し、アプリケーションの高可用性を確保します。 AWS ALB Ingress コントローラーは、Kubernetes ユーザーがクラスターで Ingress リソースを宣言するたびに ALB と必要なサポートのための AWS リソースの作成をトリガーするコントローラーです。Ingress リソースは、ALB を使用して HTTP[s] トラフィックをクラスター内の異なるエンドポイントにルーティングします。 App Mesh では、EKS の内部トラフィック (別名 East-West トラフィック) は、App Mesh コントロールプレーンによって制御される Envoy サイドカーによって管理されますが、外部アクセス (別名 North-South トラフィック) は App Mesh によって管理されません。North-South トラフィックを East-West トラフィックに接続するオプションとしては次のようなものがあります。 Ingress ゲートウェイとしての Gloo。 App Mesh のゲートウェイアプリケーションを使用する ALB Ingress Controller。 App Mesh へのイングレスとしての […]

Read More