Amazon Web Services ブログ

AWS Fargate で Amazon EKS を使用するときにアプリケーションログをキャプチャする方法

 Amazon Elastic Kubernetes Service (Amazon EKS) が、AWS Fargate でアプリケーションを実行可能にKubernetes ポッドは EC2 インスタンスをプロビジョニングして管理することなく、実行できます。Fargate は すべてのポッドを VM 分離環境で実行するため、daemonsets の概念は現在 Fargate には存在しません。したがって、Fargate を使用しているときにアプリケーションログをキャプチャするには、アプリケーションがログを出力する方法と場所を再検討する必要があります。このチュートリアルでは、Fargate で実行されているポッドのアプリケーションログをキャプチャして出荷する方法を示します。 Kubernetes ログ記録アーキテクチャ 最新のアプリケーションを構築するためのゴールドスタンダードを示す Twelve-Factor App マニフェストによると、コンテナ化されたアプリケーションは、ログを stdout および stderr に出力する必要があります。これはまた、Kubernetes のベストプラクティスと見なされ、クラスターレベルのログ収集システムはこの前提で構築されています。 Kubernetes ログ記録アーキテクチャは、次の 3 つの異なるレベルを定義します。 基本レベルのログ記録: kubectl を使用してポッドログを取得する機能 (例:kubectl logs myapp – myapp はこのクラスターで実行されているポッドです) ノードレベルのログ記録: コンテナエンジンは、アプリケーションの stdout と stderr からログをキャプチャし、ログファイルに書き込みます。 クラスターレベルのログ記録: ノードレベルのログ記録に基づく。ログキャプチャエージェントは各ノードで実行されます。エージェントはローカルファイルシステムのログを収集し、Elasticsearch や […]

Read More

Amazon EMR Managed Scaling のご紹介 – クラスターを自動的にサイズ変更してコストを削減する

AWS は、Amazon EMR マネージドスケーリングをリリースすることを発表します。これは、可能な限り低いコストで最高のパフォーマンスを得るためにクラスターのサイズを自動的に変更する新機能です。EMR マネージドスケーリングにより、クラスターの最小および最大のコンピューティング制限を指定し、Amazon EMR はそれらを自動的にサイズ変更して、最高のパフォーマンスとリソース使用率を実現します。EMR マネージドスケーリングは、クラスターで実行されているワークロードに関連する主要なメトリクスを継続的にサンプリングしています。EMR マネージドスケーリングは、Amazon EMR バージョン 5.30.1 以降の Apache Spark、Apache Hive、YARN ベースのワークロードでサポートされています。* ユースケースとメリット EMR マネージドスケーリングがリリースされる前は、ワークロードパターンを事前に予測するか、アプリケーションフレームワーク (Apache Spark や Apache Hive など) の深い理解に依存するカスタム Auto Scaling ルールを作成する必要がありました。ワークロードを予測したり、カスタムルールを作成したりするのは難しく、エラーが発生しやすくなります。クラスターリソースの不適切なサイジングは、多くの場合、SLA の未達成または予測できないパフォーマンス、またはリソースの不十分な活用とコスト超過の原因となる可能性があります。 EMR マネージドスケーリングは、ワークロードに基づいてクラスターリソースのサイズを自動的に決定することでこの問題を解決し、最高のパフォーマンスと最小のコストを実現します。クラスターをスケーリングするために、ワークロードパターンを予測したり、カスタムロジックを記述したりする必要はありません。EMR マネージドスケーリングは、ワークロードに基づいて主要なメトリクスを常にモニタリングし、クラスターのサイズを最適化して、リソースの使用率を最適化します。Amazon EMR は、ピーク時にクラスターをスケールアップし、アイドル期間中に適切にクラスターをスケールダウンして、コストを削減し、クラスターの容量を最適化して最高のパフォーマンスを実現できます。数回クリックするだけで、クラスターのコンピューティング制限を設定でき、残りは Amazon EMR が管理します。EMR マネージドスケーリングを使用すると、Amazon EMR は 1 分の粒度で高解像度のメトリクスも生成します。これにより、Amazon EMR マネージドスケーリングが受信ワークロードにどのように反応するかを視覚化できます。詳細については、「マネージドスケーリングのメトリクスを理解する」を参照してください。 例を挙げて説明するため、EMR マネージドスケーリングを使用して EMR クラスターを設定し、1 ~ 20 の間のノードにスケーリングしました (ノードあたり 16 […]

Read More

Amazon Elastic Kubernetes Service で Kiosk にソフトマルチテナンシーをセットアップする

 はじめに 現在、同じ Kubernetes クラスターで実行されている複数のテナント間を完全に分離することは不可能です。その理由は、Kubernetes がクラスターごとに 1 つのコントロールプレーンを持ち、クラスターで実行されているすべてのテナントが同じコントロールプレーンを共有するように設計されているためです。1 つのクラスターで複数のテナントをホストすると、いくつかの利点がもたらされます。主な利点には、効率的なリソースの利用と共有、コストの削減、設定のオーバーヘッドの削減があります。 ただし、マルチテナントの Kubernetes セットアップでは、リソースの共有とセキュリティに関して特殊な課題が生じます。これについての理解を深めましょう。共有クラスターの目標の 1 つは、各テナントが利用可能なリソースを公平に共有し、その要件を満たすことです。この場合に緩和する必要があると考えられる副作用に、ノイズの多い隣接効果があります。これは、テナント間で適切なレベルのリソース分離を保証することにより対処します。2 番目の課題にして主な課題は、セキュリティです。悪意のあるテナントが他のテナントを危険にさらすことを避けるには、テナント間の分離が必須です。分離メカニズムによって実装されるセキュリティレベルに応じて、業界では共有テナンシーモデルをハードとソフトのマルチテナンシーに分割しています。 マルチテナンシー ハードマルチテナンシーは、テナント間の信頼がないことを意味し、1 つのテナントは他のテナントの何にもアクセスできません。このアプローチは、たとえば、互いに知られていない複数のテナントをホストするサービスプロバイダーに適しています。このセットアップの主な焦点は、テナント間でビジネスを完全に分離することです。オープンソースコミュニティでは、この課題を解決するための作業が進行中ですが、このアプローチはまだ本番ワークロード全体では広く使用されていません。 ハードマルチテナンシーの対極にあるのが、ソフトマルチテナンシーです。これは、同じ組織またはチームの一部である可能性のあるテナント間に信頼関係があることを表します。このアプローチの主な焦点は、セキュリティの分離ではなく、テナント間のリソースの公平な利用です。 オープンソースコミュニティには、ソフトマルチテナンシーを実装するための取り組みがいくつかあり、その 1 つが Kiosk です。Kiosk は、Kubernetes クラスターにソフトマルチテナンシーを実装するためのオープンソースフレームワークです。この記事では、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに実装するためのステップバイステップガイドを示します。 初期設定 セットアップを続行する前に、次の前提条件を満たしていることを確認してください。 AWS アカウントにログインします。 AWS マネジメントコンソールで Amazon EKS クラスターを作成します。 ローカルマシンから Amazon EKS クラスターに接続します。 ローカルマシンに kubectl をインストールします。これは、Kubernetes クラスターを制御するためのコマンドラインツールです。 ローカルマシンに helm バージョン 3 をインストールします。これは Kubernetes […]

Read More

Amazon SageMaker Ground Truth を使用してジョブにラベルを付けるためのカスタム Angular アプリケーション構築

 データサイエンティストが教師あり学習で問題を解決しようとする場合、通常、モデル構築の開始前に高い品質のラベル付きデータセットを準備する必要があります。Amazon SageMaker Ground Truth を使用することで、デキストの分類やオブ​​ジェクトの検出などさまざまなタスクのデータセットを簡単に作成し、誰でもアクセスできるようになります。 Ground Truth はカスタムのユーザー定義タスクのデータセットを構築し、どんなものにも注釈を付ける際にも役立ちます。この機能により、以下のことを実現できます。 ラベル付けの手順の間にトリガーできるカスタム AWS Lambda 関数。これにより、フィルタリングの例または Amazon Translate や Amazon Rekognition などの他のサービスを使用してメタデータを追加するなどの事前ラベル付けのカスタムロジック、さらにラベルの統合または品質管理のためのラベル付け後のロジックを使用できるようになります。 Ground Truth ワークフローと完全統合する HTML および JavaScript を使用した独自のユーザーインターフェイスを構築できるカスタムウェブテンプレート。これらのテンプレートは Crowd HTML 要素で簡単に構築できます。Crowd HTML 要素とは、カスタムテンプレートのブロックのように配置できるテキスト、動画、音声のラベル付けジョブに使用される一般的な UI 要素のセットです。 対象分野のエキスパートがそろうプライベートチームを増強する必要がある場合は、AWS Marketplace および Amazon Mechanical Turk のスキルと専門知識を持つ人材の大規模なセット。厳しい審査を通過した AWS Marketplace のパートナーは、さまざまな業界のニーズ(医療向けのラベル付けなど)に適合する動画や画像注釈の特定のスキルだけでなく、多数の言語にも対応しています。 分類学に従った複雑な分類、非常に大きなマルチクラス分類、自動運転でのラベル付けタスクのような込み入ったラベル付けタスクの場合、ラベル付けを行う担当者のためにより複雑なフロントエンドアプリケーションを構築する必要がある場合があります。Angular のようなフロントエンドフレームワークはモデルビューコントローラ (MVC) といった有用な設計パターンを作成するので、こうした場合に役立ちます。このため、コードベースがより堅牢となり、UX/UI デザイナーやソフトウェアデベロッパーからなる大規模なチームによるメンテナンスが容易になります。 この投稿では、Angular と Angular 要素を使用して、Ground Truth にうまく連携する完全にカスタマイズ可能なソリューションを作成する方法について解説します。このチュートリアルでは、Ground Truth […]

Read More

ロールの連鎖を使用して、Amazon Redshift Spectrum 外部テーブルへのアクセスを Amazon Redshift IAM ユーザーとグループに制限する

 Amazon Redshift Spectrum では、Amazon Redshift クラスターから中央 AWS Glue メタストアを使用して、Amazon Simple Storage Service (Amazon S3) データレイクのデータをクエリすることができます。この機能により、ご使用中の Amazon Redshift データウェアハウスにおけるペタバイト規模のデータ保存制限がなくなり、エクサバイトのデータへの拡張を低予算でできるようになります。Amazon EMR と同様に、オープンデータ形式と低料金のストレージによるメリットを享受しながら、Redshift Spectrum ノードを数千に拡張し、データのプル、フィルタリング、投影、集約、グループ化、ソートなどが行えます。Redshift Spectrum はサーバーレスであり、プロビジョニングや管理が不要な点で、Amazon Athena と同じです。お支払いは、1 TB のデータスキャンごとに 5 USD のみです。今回の記事では、ロールの連鎖を使用したきめの細いアクセス制御を有効化し、ユーザーの要求に忠実なアクセス管理を実現するための、Amazon Redshift でのセキュリティ設定方法をご説明していきます。 RedShift Spectrum を使用して Amazon Redshift と Amazon S3 のデータレイクを統合する、レイクハウスアプローチの使用を開始する際、クラスターにある異なる外部スキーマにアクセス権を付与するためには一定以上の柔軟性が必要です。たとえば、ここでは次のようなユースケースを考えます。2 つの Redshift Spectrum スキーマ(SA および SB)が、(それぞれに、A と B という)2 つのデータベースに対し AWS Glue […]

Read More

Woot がお買い得品を拡大するために Amazon DocumentDB (MongoDB 互換) を使用する方法

 Woot! は 2004 年に設立され、2010 年にアマゾンが買収した元祖デイリーディールサイトです。Woot は当初、毎日 1 つの製品を売り切れるまで販売していましたが、現在は 7 つのカテゴリーでその日のお買い得品とその他期間限定オファーを提供しています。私のチームは Woot でリテールカタログサービスを担当しており、これは Woot のさまざまなフロントエンドサービスとユーザーインターフェイスにお買い得品を提供します。Woot が年々成長する中で私たちが直面した問題の多くは、スケーリング限界に達した古いレガシーシステムに起因するものでした。 この記事では、Woot でご覧いただける製品カタログとお買い得品の原動力となるセルフホスト型の MongoDB データベースを Amazon DocumentDB (MongoDB 互換) にどのように移行したかについて説明していきます。また、コストを削減しながらパフォーマンス、スケーリング、および俊敏性を向上させる上で Amazon DocumentDB がどのように役立ったかについても説明します。 アプリケーションアーキテクチャ Woot のリテールカタログサービスは Amazon DocumentDB をそのプライマリデータベースとして使用しています。Amazon DocumentDB 内では、データがアイテム (Woot が販売する製品)、オファー (時間と数量によって制限される販売対象アイテム)、およびイベント (お客様に売り出されるオファーのグループ) のコレクションに分類されます。私たちのバックエンドシステムは、主に C#/.Net (レガシー .Net Framework Windows サービスとサーバーレス .Net Core マイクロサービススタックの組み合わせ) を使用します。現在、Windows IIS API が Amazon […]

Read More

Amazon RDS for PostgreSQL 環境の自動バキュームを理解する

 PostgreSQL は、多くのエンタープライズデベロッパーや新興企業に推奨されるオープンソースリレーショナルデータベースになり、主要なビジネスアプリケーションやモバイルアプリケーションを強化しています。アマゾン ウェブ サービス (AWS) は、完全マネージド型のリレーショナルデータベースサービスとして、Amazon Relational Database Service (Amazon RDS) および Amazon Aurora を提供しています。Amazon RDS for PostgreSQL により、クラウドで PostgreSQL デプロイを簡単にセットアップ、操作、スケーリングできます。コマンドをいくつか使用するだけで、本稼働データベースのインスタンスを AWS で起動して実行することができます。オンラインデータベースを使用すれば、データベース管理者 は多くのメンテナンスタスクや管理タスクから解放されます。ただし、VACUUM など、データベースの使用状況に基づいて綿密なモニタリングと変更を必要とするメンテナンスタスクがあります。自動バキュームは、バキュームの操作を自動化するプロセスです。 この記事では、自動バキュームプロセスとその重要性について説明します。また、パフォーマンスを向上させるための自動バキューム設定を調整することと、オフにすることの欠点についても説明します。 PostgreSQL の MVCC PostgreSQL は多版型同時実行制御 (MVCC) を使用して、データの変更を実行するときに行を複数のバージョンで維持しています。テーブルに対する UPDATE および DELETE 操作中、データベースは古いバージョンの行を保持します。これは、他の実行中のトランザクションがデータのビューに一貫性を持たせることを要求する場合があるためです。PostgreSQL では、データベースを変更するすべてのステートメントが、xid と呼ばれるトランザクション ID を生成します。行のステータスは、xmin と xmax という 2 つの非表示列の xid を用いて追跡します。 1 つの列を持つテーブル test を考えてみましょう。行を挿入するには、次のコードを参照してください。 postgres=# CREATE […]

Read More

Kubernetes サービスアカウントのクロスアカウント IAM ロール

 サービスアカウントへの IAM ロール (IRSA) の導入により、Kubernetes でのワークロード要件に固有な IAM ロールを作成できるようになりました。このため、ノードレベルではなくポッドレベルでの詳細に設定されたロールを作成でき、最低限の特権のセキュリティ プリンシパルも有効になります。このブログ投稿では、ポッドのクロスアカウントロールを引き受ける必要があるユースケースを見ていきます。 ユースケース デベロッパーアカウントと shared_content AWS アカウントがある、次のシナリオを考えてみましょう。Amazon Elastic Kubernetes Service (Amazon EKS) クラスターのポッドとしてデベロッパーアカウントで実行する開発ワークフローでは、shared_content アカウントの pics S3 バケットに保存されているいくつかの画像にアクセスする必要があります。 IRSA 以前の手順 IRSA 導入前に shared_content アカウントの pics バケットにアクセスするには、次の手順を実行します。 shared_content アカウントに S3_Pics ロールを作成し、shared_content アカウントとデベロッパーアカウントの間に信頼関係を作成します。 S3_Pics ロールにポリシーを添付して、ReadOnlyAccess が pics バケットへのアクセスのみを許可するようにします。 Amazon EC2 信頼関係ポリシーをデベロッパーアカウントの Amazon EKS (EKS) ワーカーノードロールに添付します。. EKS ワーカーノードのロールにポリシーを添付し、EKS ワーカーノードが sts:AssumeRole 操作を実行できるようにします。 […]

Read More

[AWS Black Belt Online Seminar] Container Service Update 資料及び QA 公開

先日 (2020/6/24) 開催しました AWS Black Belt Online Seminar「Container Service Update」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200624 AWS Black Belt Online Seminar Container Services Update from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. 6月上旬に「今後数か月で、AWS Fargate は LATEST フラグをプラットフォームバージョン (PV) 1.4.0 に更新する予定です。」という通知がされていますが、「今後数か月」はどの程度の期間と考えればよいでしょうか?1.4.0 の移行のどちらを優先するかを決めたい考えております。 A. 現在アナウンスさせて頂いている時期は、2020-3Q、2020 年 7 月 – 9 月となっております。下記 Blog でもご案内しておりますが、正式な発表をお待ちください。 日本語訳:https://aws.amazon.com/jp/blogs/news/aws-fargate-platform-versions-primer/ 原文:https://aws.amazon.com/blogs/containers/aws-fargate-platform-versions-primer/ Q. Docker Engine を使っていたら、platform を […]

Read More

[AWS Black Belt Online Seminar] Amazon Cognito 資料及び QA 公開

先日 (2020/06/30) 開催しました AWS Black Belt Online Seminar「Amazon Cognito」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200630 AWS Black Belt Online Seminar Amazon Cognito from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. ユーザープール、Cognito ID プールはどこに保存されるのでしょうか?例えば貴社でご用意する Cognito 用インスタンスのローカル等に保存されるイメージでしょうか? A. お客様が指定された AWS リージョン内の Amazon Cognito 環境内に保存されます。 Q. ユーザープールに登録した情報(usename、password、email, tel)のバックアップとリストアは、どのように行えばよいですか? A. Cognito ユーザプールはバックアップやリストアの機能は提供していませんが、ユーザプールに登録された情報は、安全に保存されています。そのため、単一リージョン内での耐久性では不十分な場合や操作ミスからの復旧が、バックアップやリストアの目的になるかと思われます。 前者への対応としては、定期的に全ユーザの属性を読み取って S3 や DB 等に保存しておく、あるいはユーザの新規・変更時に都度 DB にも記録する、ログイン時に発行される ID トークンの内容を都度 DB […]

Read More