Category: Containers

この投稿は、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 […]

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

チームが 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 […]

この投稿は、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 […]

マイクロサービスという用語は、話し相手に応じて異なる意味と利点を持ちます。しかし、私の意見と一致した利点の 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% […]

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

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

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 へのイングレスとしての […]

 Weaveworks の Anita Buehrle 氏によるゲスト投稿です。 ゲームパブリッシャーにとって最も悩ましいのは、可能な限り迅速にプレイヤーに新機能を提供する能力です。新機能を迅速かつ確実に提供しなければならないだけではなく、その提供は、コストを最適化しつつ、セキュリティを維持する方法で行われる必要があります。GitOps を使用した継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインは、ゲームパブリッシャーがゲームを改善し、開発ライフサイクルを通じて新しい機能を提供するための効果的な方法です。この投稿では、GitOps のベストプラクティスと組み合わせた CD パイプラインを使用して、安全かつ費用対効果の高いスケーラブルな方法で、AWS の EKS クラスターにゲームバイナリとそのアセットを自動的に配布する方法を説明します。 CI/CD パイプラインアーキテクチャの概要 以下の図は、CI/CD パイプラインアーキテクチャとそのデータフローを示しています。GitOps を使用して、インフラストラクチャと、git のゲームのアプリケーション設定の両方を、信頼できる唯一のソースとして管理します。すべてが git に保持されているため、開発者は、クラスターに直接ログインすることなく、EKS で実行されているゲームサーバーの運用と更新のデプロイのためのプルリクエストを作成します。GitOps を使用すると、プロダクションクラスターの状態が、ソース管理下にある宣言的な設定と継続的に比較されます。 GitOps は、CI システムが新しくプッシュされたコードをテストして統合したことを前提としています。パイプラインの CI 部分は、Docker イメージを構築して Elastic Container Registry (ECR) にプッシュします。レジストリに新しく構築されたイメージを使用して、Flux CD がそこから引き継ぎます。Flux は、クラスターで実行され、ECR で新しいイメージを監視する GitOps オペレーターです。Flux は、新しいイメージが ECR にプッシュされたことに気付くと、対応するマニフェストファイルをチェックアウトし、それを更新してから再度 git にチェックインします。その後、新しいイメージがクラスターに自動的にデプロイされ、ゲームサーバーが更新され、git に保持されている信頼できるソースに対してその状態が維持されます。   ゲーム開発に継続的デプロイ (CD) を使用する理由 ゲームサーバーのデプロイを管理するために GitOps […]

 集中ログは、Kubernetes クラスターを大規模に実行および管理するための重要なコンポーネントです。開発者はアプリケーションのデバッグとモニタリングのために、運用チームはアプリケーションのモニタリングのために、セキュリティはモニタリングのために、それぞれログにアクセスする必要があります。これらのチームには、ログの処理と保存に関する異なる要求事項があります。このブログ記事では、Amazon CloudWatch と組み合わせた AWS for Fluent Bit を使用してログを集中管理するソリューションを紹介します。 AWS for Fluent Bit は Fluent Bit 上に構築されたコンテナであり、ログフィルター、パーサー、およびさまざまな出力先へのルーターとして設計されています。AWS for Fluent Bit は、Amazon CloudWatch、Amazon Kinesis Data Firehose、Amazon Kinesis Data Streams などの AWS のサービスのサポートを追加します。 ソリューションの解説の前に、Fluent Bit によってログが処理され、出力先に送信される方法を見てみましょう。ログは最初に Input 経由で取り込まれます。Kubernetes の場合、Input は Docker がそのホスト上のコンテナの stdout および stderr から生成したコンテナログファイルです。この Input は Docker ログ形式を処理し、ログエントリで時間が適切に設定されていることを確認します。 [INPUT] Name tail Tag kube.* Path […]