Amazon Web Services ブログ

Category: Compute

Fluent Bit for Amazon EKS on AWS Fargate をリリース

本投稿は、Akshay Ram, Prithvi Ramesh, Michael Hausenblas による寄稿を翻訳したものです。   Container roadmap 上の issue 701 では、 EKS on Fargate 利用時の CNCF Fluent Bit を利用したログルーターのサポートについて議論していました。このブログ記事では、EKS on Fargete利用時におけるいくつかの設定ステップによってCloudWatch へ直接ログを送信する事が出来る新しい機能とそれを利用する流れをみていきましょう。 以前は、AWS Fargate 上で動くAmazon EKS の Pod から コンテナログを送信するためには サイドカーコンテナを動かす必要がありましたが、組み込みのログルーターを利用出来るようになりました。これはサイドカーをインストールしたり維持する必要が無いという事を意味しています。ユーザーはデータの送信先を選択するだけで、ログは選択した送信先にルーティングされます。 私たちは、2つの設計原則を維持しながらこの機能を構成しました。 一貫性:必要に応じて、ネイティブの Kubernetes オブジェクトを利用して、コンピューティングタイプ(EC2、マネージドノードグループ、Fargate)に渡った一貫したインターフェイスをお客様に提供する シンプル:お客様のインフラストラクチャーや add-ons をさらに管理する この設計原則に従う事で、Fluent Bit 設定言語と Kubernetes Config Map を、プライマリインターフェイスとして選択し、 Kubernetes クラスターにおける標準的な方法としてロギングを設定する様にしました。Fluent Bit をプラットフォームの中に含める事で、Fluent Bit のライフサイクル管理をシンプルにしました。ログを何処に送るかを指定するだけで、後はAWSによって管理されます。   […]

Read More

Amazon ECS deployment circuit breaker のご紹介

※日本語字幕の表示には、設定 → 字幕 → 自動翻訳 → 日本語をご選択ください EC2 および Fargate コンピュートタイプ用の Amazon ECS deployment circuit breaker をパブリックプレビューで発表しました。この機能により、Amazon ECS をご利用のお客様は、手動での作業を行うことなく、不健全なサービスデプロイを自動的にロールバックできるようになります。これにより、お客様は失敗したデプロイを迅速に発見できるようになり、失敗したタスクのためにリソースが消費されたり、デプロイが無期限に遅延したりすることを心配する必要がなくなります。 以前は、Amazon ECS でデプロイメントタイプにローリングアップデートを使用しているときに、サービスが健全な状態にならない場合、スケジューラは サービススロットリングロジック により永続的にデプロイを再試行していました。このデプロイの失敗を迅速に検知するには、追加でモニタリングの仕組みが必要であり、これは AWS CloudFormation を使用して Amazon ECS サービスをデプロイしているお客様にとっても厄介事の1つでした。 デプロイが失敗する理由はいくつかあり、例えば、コードやサービス構成に破壊的変更を加えた場合、希望のタスク数を立ち上げるために必要なリソースが不足している場合、コンテナやロードバランサのヘルスチェックに失敗した場合などです。ここで紹介したデプロイ失敗のシナリオは一部にしか過ぎず、deployment circuit breaker がどのような場面で役立つかを理解していただくための具体例として取り上げています。このブログの後半では、コンテナのヘルスチェックが失敗した場合のシナリオを例に deployment circuit breaker のデモを行います。   何をデプロイするか? デプロイするデモアプリケーションは Python Flask Web サーバを実行しており、ECS サービスを介してデプロイされたタスク定義の現在のバージョンを表示します。このサービスの作成、デプロイ、更新には AWS CLI を使用します。まずはコード、Dockerfile、タスク定義を見て、これからデプロイされる内容の理解を深めることから始めてみましょう。 この Flask アプリケーションは、タスクメタデータエンドポイントからタスクのバージョンを取得しており、ウェブサイトにアクセスすることで、ECS サービスが実行しているタスク定義のバージョンが表示されます。このアプリケーションは circuit breaker […]

Read More

新機能 – VPC Reachability Analyzer

Amazon Virtual Private Cloud (VPC) を使用すると、お客様は、論理的に分離された専用の仮想ネットワークを、AWS クラウド上で起動できます。クラウド上でお客様のフットプリントが拡大し、デプロイされるネットワークアーキテクチャの複雑さも増していく中、誤った設定が原因で発生するネットワーク接続の問題は、その解決に時間がかかるようになっています。今回、当社では、ネットワーク診断ツールである VPC Reachability Analyzer を発表できる運びとなりました。このツールでは、VPC 内の 2 つのエンドポイント間、または複数の VPC 間で、通信の到達性に関する問題を解決できます。 ネットワークが目的どおりに設定されているかを確認 Reachability Analyzer のユーザーは、仮想ネットワーク環境を全体的に制御できます。独自の IP アドレス範囲の選択、サブネットの作成、またルートテーブルやネットワークゲートウェイの設定が可能です。また、VPC のネットワーク設定のカスタマイズも簡単です。例えば、ウェブサーバー用にパブリックサブネットを作成する際、インターネットへのアクセスに、インターネットゲートウェイを使用するように構成できます。データベースやアプリケーションサーバーなど、厳しいセキュリティが必要なバックエンドシステムは、インターネットにアクセスできないプライベートサブネットに配置できます。セキュリティグループや、ネットワークアクセスコントロールリスト (ACL) など、複数のセキュリティレイヤーを使用することで、各サブネットのエンティティへのアクセスを、プロトコル、IP アドレス、ポート番号によって制御できます。 また、VPC ピアリング、もしくは AWS Transit Gateway を経由させながら、リージョン全体またはグローバルなネットワーク接続の中で複数の VPC を組み合わせれば、トラフィックを非公開にルーティングさせられます。さらに、サイトを AWS アカウントに接続して、安全な通信を行うために、VPN Gateway を使用することもできます。AWS Lambda や Amazon S3 など、VPC 外に配置された多くの AWS のサービスでは、VPC エンドポイントや AWS PrivateLink を VPC 内のエンティティとしてサポートしており、それらのエンティティとは、プライベートな通信が可能です。 このような豊富なコントロールと機能セットがあると、接続の問題を引き起こし得るような意図しない構成を行ってしまうことも、珍しいことではありません。今回リリースされた VPC Reachability […]

Read More

新発表 — Amazon EMR on Amazon Elastic Kubernetes Service (EKS)

数万社のお客様が、Amazon EMR を使用して、Apache Spark、 Hive、HBase、Flink、Hudi、および Presto などのフレームワークでビッグデータ分析アプリケーションを大規模に実行しています。EMR は、これらのフレームワークのプロビジョニングとスケーリングを自動化し、さまざまな EC2 インスタンスタイプでパフォーマンスを最適化して、価格とパフォーマンスの要件を満たします。お客様は現在、Kubernetes を使用して組織全体でコンピューティングプールを統合しています。Amazon Elastic Kubernetes Service (EKS) で Apache Spark を管理しているお客様の一部には、EMR を使用して、フレームワークのインストールと管理、AWS のサービスとの統合などの手間のかかる作業を排除したいと考えているお客様もいらっしゃいます。さらに、EMR が提供するより高速なランタイムや開発およびデバッグのツールも活用したいと考えています。 本日、Amazon EMR on Amazon EKS の一般提供を発表いたします。これは、EMR の新しいデプロイオプションであり、EKS でのオープンソースのビッグデータフレームワークのプロビジョニングと管理を自動化できます。EKS で EMR を使用すると、同じ EKS クラスターで Spark アプリケーションを他のタイプのアプリケーションとともに実行し、リソース使用率を向上させ、インフラストラクチャ管理を簡素化することができます。 他のタイプのアプリケーションと同じ EKS クラスタに EMR アプリケーションをデプロイできるため、リソースを共有し、すべてのアプリケーションを運用および管理する単一のソリューションで標準化できます。最新のフレームワークへのアクセス、パフォーマンスが最適化されたランタイム、アプリケーション開発用の EMR Notebooks、デバッグ用の Spark ユーザーインターフェイスなど、現在 EC2 で使用しているのと同じ EMR 機能をすべて EKS で利用できます。 Amazon EMR は、アプリケーションをビッグデータフレームワークを使用してコンテナに自動的にパッケージ化し、他の […]

Read More

Amazon EKS が、マネージド型ノードグループでの EC2 スポットインスタンスのプロビジョニングと管理をサポート

この記事は、Amazon EKS now supports provisioning and managing EC2 Spot Instances in managed node groups を翻訳したものです。 Amazon Elastic Kubernetes Service (Amazon EKS) を使用すると、アップストリームのKubernetes を利用した、セキュアで可用性の高いKubernetes クラスターを AWS で簡単に実行できます。2019 年にマネージド型ノードグループがサポートされ、EKS はクラスターの基盤となる EC2 インスタンス(ワーカーノード)をプロビジョニングし、管理できるようになりました。これにより、新しいAMI がリリースされたときにノードをローリングアップデートしたり、Kubernetes バージョンを更新したりといった、運用のための作業が非常に簡単になりました。EKS のマネージド型ノードグループについて詳しく知るには、アナウンス時のブログ及びドキュメントをご参照ください。 AWS public containers roadmap にお客様より寄せられたご要望を受けて、EKS はマネージド型ノードグループをさらに使いやすくするために機能を強化してきました。例えば、カスタムAMI の指定、起動テンプレートの利用といった機能拡張を実施しました。同様に、お客様の関心が高かった機能の一つが、マネージド型ノードグループでスポットインスタンスを起動、管理できるようにするというものです。 Amazon EC2 スポットインスタンスを利用すると、EC2 が予備として確保しているキャパシティーを利用して、大幅な割引価格で EC2 インスタンスを実行できます。 EC2 がこの予備キャパシティーを必要とする際には、スポットインスタンスは 2 分前に通知を受けて中断されることがあります。スポットインスタンスを Kubernetes のワーカーノードとして使用するというのは様々な種類のワークロードで非常によく使われるパターンです。ステートレスなAPI エンドポイントやバッチ処理、ML のトレーニング、Apache Spark […]

Read More

re:Invent 2020: AWS Containers Track

re:Inventは11月30日 (月) 〜12月18日 (金) の3週間を通して開催される無料かつ完全オンラインのカンファレンスです。 今週より、登録済みのお客様は多岐に渡るAWSサービスに関するライブ及びオンデマンドのセッションへアクセスすることができます。本記事ではコンテナサービスのトラック、例えば Amazon ECS、Amazon EKS、AWS Fargate、Amazon ECR、AWS App Meshに関連するセッションについてご紹介させていただきます。また、お客様のフィードバックに基づき、今年は過去人気の高かった“Getting Started”セッションやリーダシップトーク、お客様事例のセッションを復活させました。 去年のre:Invent 2019からの進化をお客様へご共有できること、心より嬉しく思います。是非ご登録いただき、アジェンダよりご覧になりたいセッションをカレンダーへ追加してください。 ローンチセッション An introduction to Amazon ECS Anywhere, Massimo Re Ferre, Principal Technologist Amazon ECS キャパシティプロバイダーは、コンテナ化されたワークロードをさまざまなタイプのコンピュートキャパシティで実行できるようにする柔軟なルール定義機能およびそのキャパシティのスケーリング管理機能を提供するものです。本セッションでは、“オンプレミス”キャパシティプロバイダーがどのようにして多種のキャパシティ上で起動するAmazon ECSタスクやサービスを統一されたAPIを使って、コントロールプレーンの追加的ソフトウェアが必要なく管理できるかを見ていきます。オンプレミス、或いは別のクライド上でコンテナをAmazon ECSからオーケストレーションする方法についてご案内します。 セッション詳細 12月9日 2020 | 7:30 AM – 8:00 AM JST 12月9日 2020 | 3:30 PM – 4:00 PM JST 12月9日 2020 | […]

Read More
EKS Managed Addons

Amazon EKS add-ons のご紹介: Kubernetes 運用ソフトウェアのライフサイクル管理

この記事は、Introducing Amazon EKS add-ons: lifecycle management for Kubernetes operational software を翻訳したものです。 当初から、Amazon Elastic Kubernetes Service (Amazon EKS) の目標は、Kubernetes クラスター管理の専門家ではなくても AWS 上で Kubernetes を簡単に実行できるフルマネージドサービスを構築することでした。Amazon EKS が最初にローンチしたとき、それはフルマネージドな Kubernetes コントロールプレーンを意味していました。やがて、お客様からはクラスターに必要なコンピュートパワーの管理を支援してほしいという要望が出てきました。1 年前には、EKS Managed Node Groups と AWS Fargate のサポートを導入しました。 お客様からはさらなる改善のご要望をいただいていました。本日は、フルマネージドな Kubernetes クラスターを提供するための主要なステップである新機能、EKS add-ons について紹介したいと思います。EKS add-ons を使用すると、Kubernetes アプリケーションをサポートするための重要な機能を提供する運用ソフトウェアまたはアドオンを構成、デプロイ、更新することができます。これらのアドオンには、Amazon VPC CNI のようなクラスタネットワーキングのための重要なツールのほか、可観測性、管理、スケーリング、セキュリティのための運用ソフトウェアが含まれます。 本日より Amazon VPC CNI plugin から、Amazon EKS では、新しいクラスターを作成するとき、またはクラスターの実行後いつでもアドオンを有効にできるようになりました。EKS は、クラスター上でアドオンソフトウェアを起動し、1 […]

Read More

re: Invent 2020 — 12月1日 (火曜日) の事前発表

先ほど、Andy Jassy から AWS の今後のローンチに関するヒントをもらいました。それらの準備が整ったときにはもっと沢山のことをお話したいのですが、それまでお待ちいただけるように、先行発表された内容を要約したいと思います。 小型化された AWS Outposts のフォームファクター – スペースに限りがあり、低レイテンシーのコンピューティングキャパシティにアクセスする必要がある支社、工場、小売店、医療クリニック、病院、およびセルサイトなどのロケーションに最適な新しい 2 つの AWS Outposts サイズが導入されます。1U (ラックユニット) Outposts サーバーには AWS Graviton 2 プロセッサーが搭載され、2U Outposts サーバーには Intel® プロセッサーが搭載されます。どちらのサイズも EC2、ECS、および EKS のワークロードをローカルで実行でき、プロビジョニングと管理はすべて AWS が行います (自動化されたパッチ適用と更新を含む)。 Amazon ECS Anywhere – 近々、Amazon Elastic Container Service (ECS) を独自のデータセンターで実行することが可能になり、オンプレミスとクラウドの両方で稼働する単一のコンテナオーケストレータを選択して標準化することができるようになります。同じ ECS API にアクセスでき、ECS リソースは、すべて同じクラスター管理、ワークロードスケジューリング、およびモニタリングツールとユーティリティを使用して管理できます。Amazon ECS Anywhere は、既存のオンプレミスのワークロードをコンテナ化し、ローカルで実行してから、それらを AWS クラウドに接続することも容易にします。 Amazon EKS Anywhere […]

Read More

プレビュー開始 – より優れたスループットを提供する、さらに大規模で高速な io2 Block Express EBS ボリューム

Amazon Elastic Block Store (EBS) ボリュームは、2008 年の発売以来、EC2 の必要不可欠なコンポーネントです。現在、特定のユースケースに対応し、指定されたパフォーマンスが得られるように設計された 6 種類の HDD ボリュームおよび SSD ボリュームから選択できます。 今年初めに、以前の io1 ボリュームよりも 100 倍高い耐久性と 10 倍の IOPS/GiB を備えた io2 ボリュームを発売しました。io2 ボリュームは、ハイパフォーマンスでビジネスクリティカルなワークロードなど、I/O 負荷が高くレイテンシーの影響を受けやすいアプリケーションに最適です。 さらに進化 本日から、さらに優れたパフォーマンスを提供する io2 Block Express ボリュームのプレビューを開始します! このボリュームは、AWS Nitro System の一部として実装された高度な通信プロトコルを活用した新しい EBS Block Express アーキテクチャに基づいて構築され、最大 256 K IOPS と 4000 MBps のスループット、最大 64 TiB のボリュームサイズを実現します。すべてミリ秒未満で、低分散 I/O レイテンシーです。スループットは、プロビジョンド IOPS ごとに […]

Read More

AWS Lambda の新機能 – コンテナイメージのサポート

AWS Lambda では、サーバーについて気にすることなくコードをアップロードして実行できます。多くのお客様に Lambda のこの仕組みをご活用いただいていますが、開発ワークフローのためにコンテナツールに投資した場合は、Lambda でのアプリケーションの構築に同じアプローチを使用することが難しくなります。 この問題に対応するため、Lambda 関数を最大 10 GB のコンテナイメージとしてパッケージ化し、デプロイできるようになりました。これにより、機械学習やデータ集約型のワークロードなど、大きな依存関係に頼る大規模なワークロードを簡単に構築してデプロイできます。ZIP アーカイブとしてパッケージ化された関数と同様に、コンテナイメージとしてデプロイされた関数は、同様の操作のシンプルさ、自動スケーリング、高可用性、多数のサービスとのネイティブ統合による恩恵を受けます。 当社では。サポートされているすべての Lambda ランタイム (Python、Node.js、Java、.NET、Go、Ruby) のベースイメージを提供しているため、コードと依存関係を簡単に追加することができます。Amazon Linux ベースのカスタムランタイム用のベースイメージも用意しており、これを拡張して Lambda ランタイム API を実装する独自のランタイムを含めることができます。 Alpine や Debian Linux をベースにしたイメージなど、独自のベースイメージを任意で Lambda にデプロイできます。Lambda を操作するには、これらのイメージに Lambda ランタイム API を実装する必要があります。独自のベースイメージの構築を容易にするため、当社ではサポートされているすべてのランタイムにランタイム API を実装する Lambda Runtime Interface Clients をリリースしています。これらの実装は、ネイティブのパッケージマネージャーを介して利用できるため、イメージ内で簡単に取得でき、オープンソースライセンスを使用してコミュニティと共有されます。 また、Lambda Runtime Interface Emulator をオープンソースとしてリリースします。これにより、コンテナイメージのローカルテストを実行して、Lambda にデプロイした際に実行されることを確認することができます。Lambda Runtime Interface Emulator は、AWS が提供するすべてのベースイメージに含まれており、任意のイメージでも使用できます。 コンテナイメージは、Lambda Extensions […]

Read More