Category: Containers

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

  概要 つい最近まで、ECS クラスター内での EC2 インスタンスの数を、タスクとサービスに合わせてスケーリングさせようとすると、難しい問題の発生することがありました。  ECS クラスターは必ずしも必要なときにスケールアウトするわけではなく、スケールインは注意深く扱わないと可用性に影響を及ぼします。ときには、顧客はこの課題に対応するため、Lambda 関数などのカスタムの手法、カスタムのメトリクス、そして重量挙げにも例えられるような他の手段に訴えましたが、あらゆる状況でうまくいく単一のアプローチはありませんでした。もちろん、タスクを EC2 インスタンスの代わりに Fargate で実行すれば、クラスターのスケーリングの必要性は全くなくなりのですが、すべての顧客がすべてのワークロードで Fargate を採用する用意ができている、または用意ができるわけではありません。 ECS クラスター Auto Scaling (CAS) は、EC2 Auto Scaling グループ (ASG) のスケーリングを管理する、ECS のための新しい機能です。CAS を使えば、ECS が ASG を自動的にスケーリングするように構成できるので、自分のタスクにのみ注意を集中できます。ECS は必要に応じて ASG がスケールインおよびスケールアウトできるようにします。それ以上の介入は必要ありません。CAS は、ECS クラスターとユーザーが使用する ASG の間をリンクする、ECS のキャパシティプロバイダに依存します。それぞれの ASG は 1 つのキャパシティプロバイダと関連付けられ、キャパシティプロバイダはただ 1 つの ASG を持ちますが、1 つの ECS クラスターには多数のキャパシティプロバイダを関連付けることができます。クラスター全体を自動的にスケーリングするために、それぞれのキャパシティプロバイダが、関連している ASG のスケーリングを管理します。 CAS をローンチする際の私たちの目標の 1 […]

2019 年 12 月、Amazon Elastic Kubernetes Service を使用して AWS Fargate で Kubernetes ポッドを実行できることを発表しました。Fargate を使用すると、Kubernetes アプリケーションの EC2 インスタンスを作成または管理する必要がなくなります。ポッドが起動すると、Fargate はそれらを実行するために計算リソースをオンデマンドで自動的に割り当てます。 Fargate は、マイクロサービスの実行とスケーリングに最適です。特に、スパイクが発生し、予測できないトラフィックパターンがある場合に役立ちます。Amazon Elastic Load Balancing Application Load Balancer (ALB) は、Kubernetes クラスターで実行されているポッドなど、複数のターゲット間でのアプリケーションレイヤー (レイヤー 7) で着信トラフィックを負荷分散する人気のある AWS サービスです。マイクロサービスのようなトラフィックを取得するための優れた方法です。 このブログでは、オープンソースの ALB Ingress Controller を使用して、Fargate ポッドへの入力ベースの負荷分散のために EKS クラスターで AWS Application Load Balancer (ALB) をセットアップする方法を示します。ALB Ingress Controller を使用する Kubernetes Ingress の詳細については、こちらの投稿をご覧ください。 開始するには、Amazon […]

昨年 (2019/11/27) 開催しました AWS Black Belt Online Seminar「Amazon CloudWatch Container Insights で始めるコンテナモニタリング入門」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 資料P48 のCloudWatch LogsのEKSのロググループ名で以下の通り記載誤りがございました。資料は正しい内容に修正した上で公開いたします。 誤） EKSの場合：/aws/ContainerInsights/< Cluster名>/performance 正） EKSの場合：/aws/containerInsights/< Cluster名>/performance   20191127 AWS Black Belt Online Seminar Amazon CloudWatch Container Insights で始めるコンテナモニタリング入門 from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. Fargateの場合、ECS インスタンスのメトリクスは見れるのでしょうか？ A. Fargate 起動タイプにおけるコンテナ実行環境となる仮想マシンは AWS が管理・運用する仕組みとなっているため、お客様の CloudWatch Container Insights 上では仮想マシンレベルのメトリクスは表示されません。 Q. […]

本日、AWS ECS Cluster Auto Scalingを発表します。この機能は、スケールアウトを高速化し信頼性を向上させる、クラスター内の空きキャパシティ管理の提供と、スケールイン時に終了されるインスタンスの自動管理を提供し、クラスターの自動スケーリングをより使いやすいものにします。 ECS Cluster Auto Scalingを有効にするには、Capacity Providerと呼ばれる新たな項目を設定する必要があります。1つのCapacity Providerは1つのEC2 Auto Scaling Groupに関連づきます。あるAuto Scaling GroupにECS Capacity Providerを関連付け、ECSクラスターにCapacity Providerを追加すると、ECSの次の2つの新機能を用いてクラスターを自動スケールできるようになります。 管理されたスケーリング。Capacity Provider Reservationという新しいメトリックに対応するスケーリングポリシーが自動的に生成され、Auto Scaling Groupにアタッチされます。 管理されたインスタンス保護。スケールイン時にコンテナーからインスタンス終了を把握できるようになります。 これらの新機能により、ECSクラスターのスケールイン・スケールアウト時の制御が可能になります。 Capacity Provier Reservation Capacity Provider Reservationと呼ばれる新しいメトリックを導入します。クラスター内のすべてのECSワークロード、つまり既存のもの、新規のもの、変更になるもの、これらすべてが必要とする、クラスターリソースの割合(パーセンテージ)が計測されます。このメトリックはCPUやメモリ使用率を用いるよりも確度の高い、素早いスケールアウトを実現するために用いられ、またクラスター内の空きキャパシティを把握することもできるようになります。また、インスタンスを新規起動せず追加のコンテナーを素早く起動できるか、といった判断も可能になります。 管理されたインスタンス保護 インスタンス保護機能により、スケールインに際してどのインスタンスを削除できるかをECSに知らせることができます。これにより稼働中のコンテナーの中断を最小限に抑えられるようになります。運用コストの最適化、またECSで稼働するコンテナーワークロードの可用性向上に役立つ機能です。 ユーザーの利点 これまで、自動スケールするコンテナーワークロードを運用していたユーザーは、多くの場合、メトリックベースのスケーリングを使っていました。メトリックの例にはCPU使用率やメモリ使用率といったものがあり、この変化に基づいてクラスターインスタンスを追加、あるいは削除するべきかを判断するスケーリングポリシーを定義していました。 単一のワークロード、もしくは穏やかに負荷が上昇するワークロード群であれば、この方式でもうまくいく場合が多かったと考えます。しかし同一クラスター上で複数種類のワークロードを稼働させるケース、また急激な負荷上昇が見込まれるワークロードに対しては、スケーリングの問題が頻発していました。理想的には、その時点のクラスターサイズで収容しきれないようなワークロードの増加に対しては、クラスターサイズをスケールアウトさせるようなスケーリングポリシーが必要です。 既存のメトリクスがコンテナー全体を対象にしたものではなく、またその時点で使用中のリソースのみを表現するものである以上、スケールアウトが緩慢に、また不安定になってしまうことは避けられませんでした。加えて、クラスター内のどこでコンテナが稼働しているのかをスケーリングポリシーが把握できないため、スケールインに際して不用意にコンテナーを終了させてしまう場合もありました。この問題はコンテナーワークロードの可用性を低下させる要因になっていました。コンテナーインスタンスの追加台数の準備、追加のスクリプト開発、あるいは手動運用などでの回避は、すべて運用コストの増大を招いていたと言えます。 スケールしてみよう！ この機能をよく理解するには手を動かしてみるのが一番だと思います。 Amazon ECS Cluster Auto Scalingは、マネジメントコンソール、AWS CLI, Amazon ECS APIのいずれからも操作可能です。この例ではAWS CLIを用い、ターミナルからクラスターを作成する流れを見ていきます。 まず2つのファイルを作成します。ひとつ目はdemo-launchconfig.jsonで、EC2 Auto Scaling Groupに起動するAmazon Elastic […]

AWS では、お客様からのフィードバックに基づいて製品ロードマップを構築します。洗練されたコンテナベースのアプリケーションを構築および運用する際に直面する特定の問題を解決するようにお客様からの依頼を受け、次の 3 つの新機能が生まれました。 Managed Node Groups for Amazon Elastic Kubernetes Service 顧客向けの革新的なソリューションの構築に集中したいので、Kubernetes インフラストラクチャを管理する面倒な作業に手間をかけたくないという声がお客様から寄せられています。 Amazon Elastic Kubernetes Service ではすでに可用性の高い Kubernetes クラスターコントロールプレーンを標準で提供していますが、AWS では Kubernetes クラスターのノード (Amazon Elastic Compute Cloud (EC2) インスタンス) も管理できるようになりました。Amazon Elastic Kubernetes Service を使用すれば、バグ修正やセキュリティパッチをノードに簡単に適用できるようになり、最新の Kubernetes バージョンにクラスターと共に更新できます。 Amazon Elastic Kubernetes Service コンソールと API を使用すればクラスターの状態を 1 か所で把握できるため、クラスターを構成するすべてのリソースを確認するためにいろいろなサービスを見て回る必要がなくなります。 Amazon EKS クラスターを新規作成するときに、今では管理対象ノードをすぐにプロビジョンできます。Amazon EKS の管理対象ノードグループを使用するのに追加料金はかかりません。プロビジョンする Amazon EKS クラスターと AWS […]

 コンテナイメージを保存する安全でプライベートな場所が必要であるという理由から、フルマネージド型のコンテナレジストリである Amazon Elastic Container Registry を使用するお客様が多くいます。先日 Amazon EventBridge のサポートを追加しました。これにより、イメージがプッシュまたは削除されたときにアクションをトリガーできるようになりました。これらのアクションは、イメージがプッシュされたときに継続的インテグレーションや継続的デプロイパイプラインをトリガーしたり、イメージが削除されたときに DevOps チームの Slack チャネルにメッセージを投稿したりできます。 この新しい機能により、複雑なワークフローも実行できます。たとえば、お客様はベースイメージでイメージをプッシュするイベントを使用し、そのベースの上に構築されたイメージの再構築をトリガーできます。このシナリオでは、ベースイメージを毎週再構築して、最新のセキュリティパッチを取得することになります。ベースイメージのリポジトリからのプッシュイベントは他のビルドをトリガーすることができ、派生したすべてのイメージにもパッチが適用されます。 この新しい機能の使用方法を説明するために、コンソールを開いて、すべての要素がどのように組み合わさるか、サンプルを使って考えてみたいと思います。 Amazon EventBridge コンソールで新しいルールを作成し、一意の名前と説明を入力します。 次にスクロールダウンして [Define pattern] を選択し、使用するイベントパターンの種類のカスタマイズを開始します。デフォルトの Event pattern ラジオボタンを選択したままにします。また、Pre-defined pattern by service も選択します。Elastic Container Registry は AWS のサービスであるため、Service Provider は [AWS] を選択します。 Service Name セクションでは、イベントソースとしてさまざまな AWS のサービスから 1 つ選択できます。ここでは、リストに新しく追加された最新の Elastic Container Registry (ECR) を選択します。最後に、このセクションでは、Event type に ECR Image Action を選択します。 この ECR […]

今日のビジネス環境において、データはイノベーションやトランスフォーメンションの基盤とされています。データを正しい方法で使えば、文字通りマーケットリーダーを目指してビジネスを推進することができます。 そのため、データの保管、保護、保全がどんなビジネスにとっても最重要事項となります。 今年のre:Inventでは、AWS がデータストレージ分野について何をどのように行っているのか網羅した 150 以上のブレイクアウトセッションやワークショップ、チョークトーク、ビルダーセッションを開催します。 データ移行の事例についてお客様からもお話しいただきます。「What’s new in AWS file storage」セッションには、Discover Financial Services 取締役の Brandon Harris 氏、専務の Mark Bixler 氏をお呼びしています。MINDBODY, Inc. のクラウドエンジニアの方からはクラウド移行についてお話しいただきます。 re:Inventをご存じない場合または見直したい場合、弊社が最近発行したAWS Storage re:Invent guide がおすすめです。 AWS Storage チームがおすすめする必見のセッションはこちらです: ブレイクアウトセッション STG201-L – リーダーシップセッション: ユニオンのストレージの状態 STG202 AWS ファイルストレージの新機能 STG208 AWS のバックアップ・復元および災害復旧ソリューション STG211 オンプレミスのファイルベースのアプリケーションで AWS ストレージを使用する方法 STG238 AWS でファイルベースのアプリケーションをリフト & シフトする STG304 [REPEAT] Network File System (NFS) の進化: Amazon […]