Amazon Web Services ブログ

Category: Amazon Elastic Kubernetes Service

Amazon EFS CSI dynamic provisioningの御紹介

このブログはMike Stefaniak (Sr. Product Manager for Amazon EKS)、Marco Ballerini (DevOps Architect)によって執筆された内容を日本語化した物です。原文はこちらを参照して下さい。 企業がワークロードの多くをKubernetesに移行するにつれ、データをコンテナの外で共有したり持続させたりする方法を必要とするアプリケーションを導入するケースが増えています。Kubernetesは、Container Storage Interface(CSI)を介してブロックおよびファイルストレージシステムをコンテナ化されたワークロードに提供することで、このニーズに対応しています。Amazon Elastic Kubernetes Service (Amazon EKS) は現在、CSIを介して、Amazon Elastic File System (Amazon EFS)、Amazon Elastic Block Store (Amazon EBS)、およびAmazon FSx for Lustreの3つのストレージオプションをサポートしています。この記事では、お客様に人気のストレージオプションであるAmazon EFSに焦点を当てます。Amazon EFSは、同じAWSリージョン内の異なるアベイラビリティーゾーンからアクセス可能な共有ファイルシステムを提供し、高い耐久性を持つように設計されています。これは、Amazon EKSクラスタが複数のアベイラビリティーゾーンにまたがっている場合、またはコンテナ化されたアプリケーションが設定ファイル、静的資産、または複数のポッドで共有される何かを保持するために永続的なストレージを必要とする場合に特に役立ちます。 Kubernetesは、同じクラスタ内のストレージ関連の業務を論理的に分離します。PersistentVolumes (PV)は、管理者によってプロビジョニングされた、又はCSIドライバを使って動的にプロビジョニングされた、クラスタ内のストレージの単位です。PersistentVolumeClaim (PVC)は、通常、ユーザーまたはアプリケーションによって作成され、ストレージ領域を必要とする時にPVを要求します。これはポッドと似ており、一般的にはアプリケーションのライフサイクルに沿って行われます。 これまで、Amazon EFS CSIドライバを使用するKubernetes管理者は、ユーザーがPVCを作成する前に、PV(および必要なAmazon EFSリソース)を静的にプロビジョニングする必要がありました。今回、Amazon EFS CSIドライバーの最新バージョンにダイナミックプロビジョニングが搭載されたことをお知らせします。ダイナミック・プロビジョニングは、EFSアクセスポイント(EFSファイルシステムへのアプリケーション固有のエントリーポイント)を使用して、単一のファイルシステムで最大120のPVを自動的にプロビジョニングすることができます。 このブログの残りの部分では、新しくリリースされたAmazon EFS CSIドライバーのバージョン1.2を使用して、ダイナミック・プロビジョニングを開始する方法を紹介します。 セットアップ ドライバは、EFS アクセスポイントを作成および管理するために IAM 権限を必要とします。IAM roles for […]

Read More

Amazon EKS on Fargate を使用してコンテナイメージをビルドする方法

この記事は、How to build container images with Amazon EKS on Fargate を翻訳したものです。 本投稿は、Container Specialist Solutions Architect の Re Alvarez-Parmar により寄稿されました。 コンテナは、開発者がアプリケーションをパッケージ化、配布、そしてデプロイする方法を簡素化するのに役立ちます。開発者は、アプリケーションコード、ライブラリ、およびその他の依存関係を含むコンテナイメージにコードをパッケージ化します。このイメージを使用して、コンテナ化されたアプリケーションを互換性のある任意のオペレーティングシステムにデプロイすることができます。2013 年の Docker のリリース以来、コンテナの実行、イメージのビルドおよびリポジトリへのプッシュが容易に行えるようになりました。 ただし、Amazon ECS や Amazon EKS のような環境で Docker を使用してコンテナをビルドするには、Docker で Docker を実行する必要がありますが、これには重大な影響があります。おそらく、Docker を使用してコンテナ化された環境でコンテナイメージをビルドするための最も魅力的ではない前提条件は、特権モードでコンテナを実行する、という要件です。これは、セキュリティ意識の高い殆どの開発者が避けたい慣行です。Docker を使用してラップトップ上でイメージをビルドしても、セキュリティに深刻な影響はない場合があります。それでも、Kubernetes クラスターでコンテナに昇格された特権を与えることは避けるのが最善です。この厳しい要件により Fargate では特権コンテナが許可されていないため、Fargate で Docker と EKS を使用してコンテナイメージをビルドすることもできなくなります。 kaniko 特権モードを必要とせずにコンテナイメージをビルドする問題に対処するために、ここ数年で新しいツールが登場しました。kaniko は、Docker と同じように、Dockerfile からコンテナイメージをビルドするツールの 1 つです。ただし Docker とは異なり、Docker デーモンに依存せずに Dockerfile […]

Read More

Amazon EKS 上の AWS App Mesh での SPIFFE/SPIRE による mTLS の使用

本記事は、Efe Selcuk、Apurup Chevuru、Michael Hausenblas による Using mTLS with SPIFFE/SPIRE in AWS App Mesh on Amazon EKS を翻訳したものです。 AWS では、セキュリティを最優先事項と考え、責任共有モデルの観点から、お客様の責任部分をケアするためのコントロールを提供しています。サービスメッシュの一般的な使用例の 1 つは、通信経路のセキュリティ対策を強化することが挙げられますが、これは AWS App Mesh でも重点的に取り組んでいます。また、mTLS を安全かつ正しく利用するという課題は、実務者の間でも議論の対象となっています。AWS は App Mesh roadmap からの mTLS (mutual TLS、相互 TLS) の要望に応え、この機能のサポートを開始しました。このブログ記事では、mTLS の背景を説明し、Amazon Elastic Kubernetes Service (EKS) クラスターを使用したエンドツーエンドの例を紹介します。 背景 mTLS にあまり詳しくない場合は、このセクションをご覧ください。そうでない場合は、ウォークスルーに進んでください。 SPIFFE (Secure Production Identity Framework for Everyone) プロジェクトは、CNCF (Cloud Native […]

Read More

Amazon EFS を利用して AWS Fargate 上の Amazon EKS でステートフルなワークロードを実行する

この記事は、Running stateful workloads with Amazon EKS on AWS Fargate using Amazon EFS を翻訳したものです。 本投稿は、Container Specialist Solutions Architect の Re Alvarez-Parmar と Sr Technical Account Manager の Vikram Venkataraman により寄稿されました。 Amazon Elastic Kubernetes Service (EKS) では、EC2インスタンスまたは AWS Fargate で Kubernetes ポッドを実行することができます。コンテナ用のサーバーレスコンピューティングエンジンである AWS Fargate を使用すると、サーバーの作成と管理、データプレーンのスケーリング、EC2 インスタンスの適切なサイズ設定、ワーカーノードのアップグレードの処理を行うことなく、Kubernetes ワークロードを実行できます。今のところ Fargate は、ステートレスなコンテナ化されたワークロードを安全で費用対効果の高い方法で実行するのに理想的です。Fargate は VM で分離された環境で各ポッドを実行し、ノードに自動的にパッチを適用するため安全です。Fargate では、ポッド用に構成したコンピューティングリソースに対してのみ課金されるため、費用対効果が高まります。最近リリースされた Amazon Elastic File System […]

Read More

EKS と Fargate、AWS Compute Savings Plans で Pod の料金を節約する

この記事は、Saving money a pod at a time with EKS, Fargate, and AWS Compute Savings Plans を翻訳したものです。 re:Invent 2019 では、Amazon Elastic Kubernetes Service (Amazon EKS) で、Kubernetes の Pod を AWS Fargate にデプロイできるようになったことが発表されました。その発表以降、多くのお客様が実際に Fargate 、つまりコンテナを実行するためのサーバーレスインフラストラクチャーに Kubernetes の Pod をデプロイしています。Fargate を利用することで、クラスターの管理やパッチの適用、セキュリティやアイソレーション、スケーリングといった様々な運用業務、「差別化にならない重労働( undifferentiated heavy lifting )」から解放されます。 Amazon EKS と Fargate の詳細については、re:Invent のブレイクアウトセッションでも掘り下げられています。 AWS Fargate は AWS Compute Savings Plans […]

Read More

AWS Inferentiaを搭載した Inf1インスタンスが東京リージョンでAmazon SageMakerに対応しました

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、シニアエバンジェリストの亀田です。 AWS Inferentiaを搭載した Inf1インスタンスが東京リージョンにおいて、SageMakerで利用可能になりましたのでお知らせいたします。 AWS Inferentia と Inf1インスタンスとは? 一般的に機械学習のビジネス利用は、データ準備、学習と推論の3つのフェーズに分かれます。このうち学習環境は高価なGPUを搭載した専用 Amazon EC2インスタンスが用いられるケースが多くありその金額が課題となりえます。Amazon SageMaker を使うと高価な学習用インスタンスは、学習が終了した時点で学習用インスタンスを自動で停止させることで無駄な課金を抑えることができ、さらに、Managed Spot Training機能を使うことで、スポットインスタンスをベースとした安価な学習を行うことが可能です。その学習の結果として推論モデルが生成され、さらにAPIが生成され商用環境に組み込まれることとなります。 概して、推論環境は高価なGPU搭載インスタンスが必要な学習環境よりそのコストは安いものとなりますが、一時的かつ反復的に行われる学習環境とことなり、常時起動が前提となることが多く、そのコストは時間とともに積みあがります。さらに、ビジネスが順調に成長した場合、学習環境は中央集権型で構築されるのに対して、推論環境は多くの環境に組み込まれそのコストが課題となっていきます。 AWS Inferentiaはこの課題を解決するためにAWSが開発した高パフォーマンスの機械学習推論チップです。高性能の推論を提供し、推論の総コストを削減し、デベロッパーが機械学習をビジネスアプリケーションに簡単に統合できるように設計されています。また、Inferentia のワークロードのパフォーマンスを最適化するのに役立つコンパイラ、ランタイム、およびプロファイリングツールから構成される AWS Neuron ソフトウェア開発キット (SDK) は、AWS Inferentia ベースの 環境で TensorFlow、PyTorch、および MXNet などの一般的なフレームワークで作成およびトレーニングされた複雑なニューラルネットモデルを実現します。推論の高速化によるコスト削減は、Neuron Cores と呼ばれる Inferentia のプロセッシングコアにより実現されます。コアはオンチップメモリに格納され、帯域幅によって制限されないモデルに高速でアクセスすることが可能です。 そして、このInferentiaチップを搭載したEC2インスタンスがAWS Inf1 インスタンスになります。単一のチップで最大 128 TOPS (1 秒あたり数兆回の操作) のパフォーマンスをサポートし、EC2 Inf1 インスタンスごとに最大 16 個の Inferentia チップを有することができます。 Inf1インスタンスはEC2、または、Amazon Elastic Kubernetes Service […]

Read More

SAP Data Intelligenceによる顧客フィードバック分析

イントロダクション 多くの企業は顧客をよりよく理解するためのプロセスがあり、データは顧客との関係を強化するための鍵となりつつあります。しかし、単にデータを収集するだけでは十分ではありません。ほとんどの組織は多くのデータにアクセスできますが、データの背後にある意味を判断するのは難しい場合があります。このブログ記事では、SAP Data Intelligence 3(DI3)、SAP HANA、Amazon S3を組み合わせてデータドリブンアーキテクチャを構築し、顧客からのフィードバックをよりよく理解し、意味のある洞察を導き出す方法を紹介します。

Read More
Benchmark CPU usage (vCPUs per 10Gbps)

Bottlerocket、Calico、eBPF で EKS ネットワークをターボチャージする

この投稿は、Tigera, Inc. の共同創設者兼 CTO である Alex Pollitt によって共同執筆されました。 先日、Amazon は Amazon Elastic Kubernetes Service (Amazon EKS) 上での Bottlerocket のサポートを発表しました。Bottlerocket は、セキュリティ、運用、および管理性を重視した、コンテナを大規模に実行するために Amazon が構築したオープンソースの Linux ディストリビューションです。Bottlerocket の詳細については、このアナウンスブログをご覧下さい。 Amazon EKS には、Amazon VPC CNI Plugin によって、Pod が VPC ルーティング可能な IP アドレスを持つことを可能にする優れたネットワーク機能が組み込まれています。この基本的なネットワーク機能に加えて、Network Policy のサポートが必要な場合、EKS は Calico をサポートしています。Amazon EKS のドキュメントで説明されているように、Calico は単一の kubectl コマンドで任意の EKS クラスターに追加できます。 では、Bottlerocket の EKS サポートによって何が変わるのでしょうか?フットプリントとリソース要件の削減に加えて、Bottlerocket は迅速なリリースサイクルも提供します。これは Bottlerocket […]

Read More

リクルートマーケティングパートナーズにおけるAmazon EKSとAWS App Meshを使った基盤安定性向上とGitOpsへの挑戦

本番環境でコンテナを利用したワークロードを構築する場合、ほとんどのケースでコンテナオーケストレーションのテクノロジが導入されます。AWS では、Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS)といったコンテナオーケストレーションに関するサービスを提供しています。 コンテナオーケストレーターの選定においては、各オーケストレーターの持つ機能や思想を理解することが重要です。Amazon ECS は、他の AWS サービスとシームレスに組み合わせることが可能であり、Amazon ECS をビルディングブロックの一つとして多様なワークロードをサポートするシステムを素早く構築可能です。Amazon EKS は、Kubernetes の持つエコシステムの利用や、カスタムリソースをクラスターに追加することにより、EKS クラスター上にワークロードの要件に応じたシステムを柔軟に構築することができます。これらの観点に加えて、ワークロードの要件を考慮した上でコンテナオーケストレーターを選択します。 一方で、ビジネスや組織の成長に伴い、コンテナオーケストレーターとワークロードがマッチしない状況が発生する場合があります。例えば、Amazon EKS でサービスを提供しているチームにおいて、サービスの拡充に伴い管理対象となる EKS クラスターやクラスター上のアプリケーションが増加した結果、Kubernetes バージョンのアップデート作業がチームで抱えきれないような負担になるかもしれません。この状況を解消する手段として、まず思いつくのがコンテナオーケストレーターの再選定ですが、コンテナオーケストレーターの移行には少なからず必要となる作業が見込まれるため、安易に決断することはできません。 しかしながら、コンテナオーケストレーターの移行により得られるベネフィットを評価できる場合、移行によるメリットが作業コストを上回る可能性があります。この評価を行うためには、現在の課題を正確に分析し、移行先となるコンテナオーケストレーターでは解決のためにどのようなアプローチが採用できるのか把握しておく必要があります。 本投稿では、リクルートマーケティングパートナーズが行なった Amazon ECS から Amazon EKS への移行を通じて、コンテナオーケストレーターの移行におけるベネフィットをどのように評価したのかを紹介します。合わせて、リクルートマーケティングパートナーズが Amazon EKS で導入したサービスメッシュと継続的デリバリーについて、その実例を紹介します。 リクルートマーケティングパートナーズ スタディサプリ ENGLISH SRE グループの大島 雅人氏、木村 勇太氏、横山 智大氏によるゲスト投稿 以下の投稿はリクルートマーケティングパートナーズの3つのブログ記事を元に再構成したものです。 概要 スタディサプリ ENGLISH の基盤を […]

Read More

Amazon EKS を利用した、ステートレスなマルチリージョンアプリケーションの運用

この記事は、Operating a multi-regional stateless application using Amazon EKS を翻訳したものです。 本投稿は、Sr Solutions Architect の Re Alvarez-Parmar と、Technical Account Manager の Avi Harari により寄稿されました。 AWS の上で運用を行う主な利点の一つは、お客様が AWS のグローバルフットプリントを利用して複数のリージョンでワークロードを実行することが、いかに簡単かという点です。ディザスターリカバリーをサポートするため、あるいはエンドユーザーとなるお客様の近くでアプリケーションを稼働させるためにマルチリージョンアーキテクチャが必要な場合、AWS はアプリケーションの可用性や信頼性、そしてレイテンシーを改善するためのビルディングブロックを提供します。本投稿では、Amazon Elastic Kubernetes Service (Amazon EKS) を使用して複数の AWS リージョンでアプリケーションを実行し、AWS Global Accelerator を使用して AWS リージョン間でトラフィックを分散する方法を示します。 本投稿での説明をシンプルにするために、複数の AWS リージョンを跨いで実行されるステートレスアプリケーションにスコープを絞って説明しています。データの永続化が必要なワークロードでは、DynamoDB グローバルテーブル、 Amazon Aurora グローバルデータベース、そして Amazon S3 クロスリージョンレプリケーションのような機能を利用することができます。本投稿では、ステートレスアプリケーションの基本的なアーキテクチャを提案しています。ステートフルなマルチリージョンアプリケーションのブループリントをビルドするために、データやデータベースレプリケーションサービスでこのアーキテクチャを補完することもできます。 Amazon EKS はグローバル化においてどのように役に立つのか Kubernetes の宣言的なシステムは、マルチリージョンデプロイメントを運用するための理想的なプラットフォームとなります。宣言的なシステムでは、desired […]

Read More