保持されている信頼できるソースに対してその状態が維持されます。クラスターを大規模に実行および管理するための重要なコンポーネントです。開発者はアプリケーションのデバッグとモニタリングのために、運用チームはアプリケーションのモニタリングのために、セキュリティはモニタリングのために、それぞれログにアクセスする必要があります。これらのチームには、ログの処理と保存に関する異なる要求事項があります。使用してログを集中管理するソリューションを紹介します。上に構築されたコンテナであり、ログフィルター、パーサー、およびさまざまな出力先へのルーターとして設計されています。サービスのサポートを追加します。よってログが処理され、出力先に送信される方法を見てみましょう。経由で取り込まれます。生成したコンテナログファイルです。ログ形式を処理し、ログエントリで時間が適切に設定されていることを確認します。インスタンスの数を、タスクとサービスに合わせてスケーリングさせようとすると、難しい問題の発生することがありました。クラスターは必ずしも必要なときにスケールアウトするわけではなく、スケールインは注意深く扱わないと可用性に影響を及ぼします。関数などのカスタムの手法、カスタムのメトリクス、そして重量挙げにも例えられるような他の手段に訴えましたが、あらゆる状況でうまくいく単一のアプローチはありませんでした。採用する用意ができている、または用意ができるわけではありません。ための新しい機能です。自動的にスケーリングするように構成できるので、自分のタスクにのみ注意を集中できます。スケールインおよびスケールアウトできるようにします。それ以上の介入は必要ありません。キャパシティプロバイダに依存します。クラスターには多数のキャパシティプロバイダを関連付けることができます。スケーリングを管理します。ポッドを実行できることを発表しました。インスタンスを作成または管理する必要がなくなります。それらを実行するために計算リソースをオンデマンドで自動的に割り当てます。マイクロサービスの実行とスケーリングに最適です。スパイクが発生し、予測できないトラフィックパターンがある場合に役立ちます。マイクロサービスのようなトラフィックを取得するための優れた方法です。セットアップする方法を示します。詳細については、こちらの投稿をご覧ください。始めるコンテナモニタリング入門」の資料を公開しました。一部についても共有しております。LogsのEKSのロググループ名で以下の通り記載誤りがございました。資料は正しい内容に修正した上で公開いたします。上では仮想マシンレベルのメトリクスは表示されません。Scalingを発表します。この機能は、スケールアウトを高速化し信頼性を向上させる、クラスター内の空きキャパシティ管理の提供と、スケールイン時に終了されるインスタンスの自動管理を提供し、クラスターの自動スケーリングをより使いやすいものにします。Providerと呼ばれる新たな項目を設定する必要があります。Groupに関連づきます。Providerを追加すると、ECSの次の2つの新機能を用いてクラスターを自動スケールできるようになります。管理されたスケーリング。Groupにアタッチされます。管理されたインスタンス保護。スケールイン時にコンテナーからインスタンス終了を把握できるようになります。これらの新機能により、ECSクラスターのスケールイン・スケールアウト時の制御が可能になります。Reservationと呼ばれる新しいメトリックを導入します。クラスター内のすべてのECSワークロード、つまり既存のもの、新規のもの、変更になるもの、これらすべてが必要とする、クラスターリソースの割合(パーセンテージ)が計測されます。このメトリックはCPUやメモリ使用率を用いるよりも確度の高い、素早いスケールアウトを実現するために用いられ、またクラスター内の空きキャパシティを把握することもできるようになります。インスタンスを新規起動せず追加のコンテナーを素早く起動できるか、といった判断も可能になります。インスタンス保護機能により、スケールインに際してどのインスタンスを削除できるかをECSに知らせることができます。これにより稼働中のコンテナーの中断を最小限に抑えられるようになります。運用コストの最適化、またECSで稼働するコンテナーワークロードの可用性向上に役立つ機能です。これまで、自動スケールするコンテナーワークロードを運用していたユーザーは、多くの場合、メトリックベースのスケーリングを使っていました。メトリックの例にはCPU使用率やメモリ使用率といったものがあり、この変化に基づいてクラスターインスタンスを追加、あるいは削除するべきかを判断するスケーリングポリシーを定義していました。単一のワークロード、もしくは穏やかに負荷が上昇するワークロード群であれば、この方式でもうまくいく場合が多かったと考えます。同一クラスター上で複数種類のワークロードを稼働させるケース、また急激な負荷上昇が見込まれるワークロードに対しては、スケーリングの問題が頻発していました。理想的には、その時点のクラスターサイズで収容しきれないようなワークロードの増加に対しては、クラスターサイズをスケールアウトさせるようなスケーリングポリシーが必要です。既存のメトリクスがコンテナー全体を対象にしたものではなく、またその時点で使用中のリソースのみを表現するものである以上、スケールアウトが緩慢に、また不安定になってしまうことは避けられませんでした。加えて、クラスター内のどこでコンテナが稼働しているのかをスケーリングポリシーが把握できないため、スケールインに際して不用意にコンテナーを終了させてしまう場合もありました。この問題はコンテナーワークロードの可用性を低下させる要因になっていました。コンテナーインスタンスの追加台数の準備、追加のスクリプト開発、あるいは手動運用などでの回避は、すべて運用コストの増大を招いていたと言えます。この機能をよく理解するには手を動かしてみるのが一番だと思います。APIのいずれからも操作可能です。CLIを用い、ターミナルからクラスターを作成する流れを見ていきます。2つのファイルを作成します。お客様からのフィードバックに基づいて製品ロードマップを構築します。つの新機能が生まれました。インフラストラクチャを管理する面倒な作業に手間をかけたくないという声がお客様から寄せられています。管理できるようになりました。バージョンにクラスターと共に更新できます。か所で把握できるため、クラスターを構成するすべてのリソースを確認するためにいろいろなサービスを見て回る必要がなくなります。クラスターを新規作成するときに、今では管理対象ノードをすぐにプロビジョンできます。管理対象ノードグループを使用するのに追加料金はかかりません。使用するお客様が多くいます。サポートを追加しました。これにより、イメージがプッシュまたは削除されたときにアクションをトリガーできるようになりました。チャネルにメッセージを投稿したりできます。この新しい機能により、複雑なワークフローも実行できます。お客様はベースイメージでイメージをプッシュするイベントを使用し、そのベースの上に構築されたイメージの再構築をトリガーできます。このシナリオでは、ベースイメージを毎週再構築して、最新のセキュリティパッチを取得することになります。ベースイメージのリポジトリからのプッシュイベントは他のビルドをトリガーすることができ、派生したすべてのイメージにもパッチが適用されます。この新しい機能の使用方法を説明するために、コンソールを開いて、すべての要素がどのように組み合わさるか、サンプルを使って考えてみたいと思います。コンソールで新しいルールを作成し、一意の名前と説明を入力します。選択し、使用するイベントパターンの種類のカスタマイズを開始します。ラジオボタンを選択したままにします。