Category: Compute

はじめに 2020年を振り返ると、どれだけ信じがたい出来事が起きたかということを認めなくてはなりません。全世界的にCOVID-19やその他の世界の出来事によって私たちの生活様式が変化し、多くの人々にとって困難なものとなりました。このパンデミックにより、企業は顧客や従業員のニーズを満たすために、ほぼ即座に運用上の変更を余儀なくされました。また、多くの企業がクラウドサービスの利用を始めました。 この数週間にわたり、毎年恒例のre:Inventカンファレンスの一環として、私たちは多くのお客様からの声を聞く機会がありました。その数社はSAPトランスフォーメーションのストーリーを世界へ共有するためのバーチャルステージを行いました。：

この記事は、Running microservices in Amazon EKS with AWS App Mesh and Kong を翻訳したものです。 本投稿は、Kong ソリューションエンジニアの Claudio Acquaviva、Kong アライアンスの Morgan Davies と共同で作成されたものです。 サービスメッシュはサービス間通信のための一般的なアーキテクチャパターンとなっている透過的なインフラストラクチャレイヤーです。Amazon EKS と AWS App Mesh を組み合わせることでマイクロサービスのための強力なプラットフォームを形成し、ロードバランシング、サービスディスカバリ、可観測性、アクセスコントロール、トレース、ヘルスチェック、サーキットブレーカーなどサービス間通信で発生する技術的な要件に対応する事ができます。 モダンなエンタープライズソリューションでは、次のカテゴリの明確な管理制御が必要です。 API エンドポイントへの外部からのイングレストラフィックをカバリングする API 管理 運用管理とサービスの状態に焦点を当てたサービス管理機能 サービスメッシュは主に 2 つ目のカテゴリに対応していますが、イングレストラフィックも同様に重要であり、スロットリング、アプリケーションとユーザの認証、リクエストログとトレース、データのキャッシングなどクラスタ全体のポリシーをサポートするソリューションから恩恵を受けることができます。これらのポリシーに加えてイングレスは使用状況の把握、課金システムの追加、運用上の閾値を超えたアラートの生成などの機能により、API のマネタイズを可能にするレイヤーです。 これらの機能はクラスタ外の周辺ツールを利用することで実現することも可能ですが、Kong for Kubernetes Ingress Controller は HPA、自己修復、RBAC、cert-manager などの Kubernetes の機能を活用して、アプリケーションと並行して稼働しているサービスメッシュを保護するソリューションを提供します。 この記事では、Amazon EKS、AWS App Mesh、Kong for Kubernetes を利用してサービスメッシュを安全に実装する方法について説明します。ここで取り上げる課題の範囲は API […]

はじめに パート1では、AWS Configマネージドルールを使用してSAPランドスケープのを自動的に監査および評価する方法をお伝えしました。また、お客様のEC2インスタンスがSAPのベストプラクティスに従って設定されていることを確認するソリューションをお伝えしました。現在、AWSはバージニア北部リージョンでは160を超えるマネージドルールを提供しています。 インフラストラクチャに加えて、お客様はアプリケーションのコンプライアンスを維持する必要もあります。ここでは、AWS Configカスタムルールについてご説明します。AWS Configカスタムルールを使用すると、マネージドルールでカバーされているものに加えて、独自の構成チェックを定義できます。基本的にAWS Configカスタムルールは、AWSリソースのリストに対してAWS Lambda関数を実行します。

この記事は、Introducing the new Amazon EKS console を翻訳したものです。 Amazon Elastic Kubernetes Service (EKS) は re:Invent 2017 にて提供を開始して以来、 Kubernetes を本番環境で利用するユーザーのニーズを満たすように急速に進化してきました。Intel、Snap、Intuit、GoDaddy、Autodesk などのお客様は、セキュリティ、信頼性、およびスケーラビリティの高さを理由に、最も機密性の高いミッションクリティカルなアプリケーションをAmazon EKS 上で実行しています。 Amazon EKS には、Kubernetes のアプリケーションや API リソースの設定を簡単に可視化できるシンプルな方法がありませんでした。問題を特定して調査するには、Kubernetes と AWS 全体を手動で追跡する必要がありました。これらの作業はすべて、特に新しいユーザーにとって、Amazon EKS を始めて、実行するのに多くの時間が必要なものでした。 2020年12月1日、我々は新しい Amazon EKS コンソールを発表できることを嬉しく思います。Amazon EKS では、Kubernetes クラスター、アプリケーション、および関連するクラウドリソースのステータスを単一の場所で確認できます。新しいコンソールを使うことで、お客様は Kubernetes 環境にまつわる情報をすぐに手に入れられるようになり、アプリケーションのさまざまなコンポーネントの依存関係をすべて理解し、適切にデプロイされていることを確認することが容易になります。 Kubernetes クラスターを詳しく見る EKS コンソールは AWS でホストされるため、追加のセットアップや設定は不要です。コンソールを開き、クラスターを選択するだけです。 Overview タブで、クラスターのワーカーノード一覧が表示されていることにまず気づくでしょう。Kubernetes コントロールプレーンから見て、これらのノードは Kubernetes アプリケーションが実行されるコンピューティングリソースです。ノードをクリックすると、Kubernetes API サーバーがこのノードについて知っているすべての情報が、もう少し詳しく表示されます。さまざまなノードをすばやく探索し、関連するEKS のマネージド型ノードグループと、そのノードが表す […]

この記事は、Zero-effort Container deployment for GraphQL and REST APIs and Web Hosting with Amplify CLIを翻訳したものです。 AWS Amplifyを使うことで、最速かつ簡単に、AWSでクラウド対応のモバイルアプリケーションやウェブアプリケーションを構築することができます。Amplifyは、フロントエンドのウェブ開発者やモバイル開発者が AWSの豊富なサービス群を活用して、革新的で多機能なアプリケーションを構築できるよう、ツール類や各種サービスを一通り備えています。 本日リリースしたAmplify CLIをお使いになることで、フロントエンドのウェブ開発やモバイル開発に携わるお客様は、コンテナを使ってAPI（GraphQL/REST）をデプロイしたり、ウェブアプリケーションをホスティングできるようになります。お客様ご自身のDockerfileまたは Docker Composeを持ち込むことで、Amplify CLIは、AWS Fargateを使用してコンテナを自動的にビルド、パッケージ、デプロイします。 メリット: 移植性の高いバックエンドの構築 – Amplify CLIは、シンプルなコンテナテンプレートを用意しているためすぐに始められます。または、お客様のチームがAPIやホスティング用のコンテナを既に使用している場合は、そのコンテナを利用することができます。 コンテナのデプロイパイプラインがすぐに使えるインフラ構成 – Amplify CLIは、VPC、サブネット、NACL、IAMポリシー、およびその他のセキュリティなどのインフラを管理するため、AWSに関する事前知識やインフラの実務経験は全く必要ありません。コンテナ間のネットワーキングは自動的に処理され、ホスティングされたサイトのSSL生成も自動的に処理されます。 ビルド＆デプロイパイプラインを労力をかけることなく作成 – Amplify CLIはCodePipelineを作成し、イメージをビルド、デプロイします。パイプラインには、ビルドアーティファクトやイメージに対するライフサイクルポリシーなど、コスト最適化のベストプラクティスが備わっています。ビルドしてAWSにデプロイするためにDockerをお使いのシステムにインストールする必要すらありません。 構築するもの : 初めに、乱数を返すExpressJSサーバーを構築 次に、Python/Flask乱数生成サーバーでFizzBuzzアルゴリズムを実行する、ExpressJSを構築。 前提条件: 最新のAmplify CLIをインストール ターミナルを開き、 npm install -g @aws-amplify/cli を実行し、最新のAmplify CLIに更新。 Amplify CLIの設定 Amplify CLIをまだ設定していない場合は、ドキュメントページのこちらのガイド に従ってください。 […]

本投稿は、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によって管理されます。   […]

※日本語字幕の表示には、設定 → 字幕 → 自動翻訳 → 日本語をご選択ください 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 […]

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

数万社のお客様が、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 は、アプリケーションをビッグデータフレームワークを使用してコンテナに自動的にパッケージ化し、他の […]

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