Category: Advanced (300)

この記事は Under the hood: FireLens for Amazon ECS Task (記事公開日: 2019 年 11 月 18 日) を翻訳したものです。 2019 年 11 月、Amazon ECS は FireLens によるカスタムログルーティングのサポートを発表しました。FireLens によって、人気の高いオープンソースのロギングプロジェクトである Fluentd や Fluent Bit を簡単に使用することができ、さまざまな AWS サービスやパートナーの宛先にログを送信することができます。 この記事では、私たちがなぜ、どのようにして FireLens を作ったのか、詳しく説明します。また、私が FireLens を使用した結果を共有し、FireLens を設定するための推奨事項を紹介します。この記事では、FireLens、Fluent Bit や Fluentd について深く掘り下げます。Fluentd や Fluent Bit に馴染みのない方は、読み進める前に、Fluentd や Fluent Bit と FireLens のドキュメントをよく理解しておくことをお勧めします。

(この記事は、Integrate GitHub monorepo with AWS CodePipeline to run project-specific CI/CD pipelines を翻訳したものです。) AWS CodePipeline は、ソフトウェアのリリースに必要なステップをモデル化、可視化、自動化できる継続的デリバリーサービスです。AWS CodePipeline を使用して、コードを構築し、稼働前の環境にデプロイし、アプリケーションをテストし、実稼働環境にリリースするまでの完全なリリースプロセスをモデル化できます。AWS CodePipeline は、コードが変更されるたびに定義されるワークフローに従って、アプリケーションを構築、テスト、デプロイします。多くの組織が GitHub をソースコードリポジトリとして使用しています。組織によっては、1 つの GitHub リポジトリに複数のアプリケーションまたはサービスをフォルダで分割して格納することを選択しています。リポジトリ内のソースコードをこのように整理する方法は、モノレポと呼ばれます。 この記事では、AWS Lambda で GitHub イベントペイロード（訳者注：GitHub 上でのアクティビティを元にトリガーされるイベント情報。詳細は GitHub イベントのドキュメントをご確認ください。）を読み取り、サービス固有のパイプラインを実行するようにカスタマイズする方法を示します。

本投稿は Open source mobile core network implementation on Amazon Elastic Kubernetes Service を翻訳したものです。 アマゾンウェブサービス (AWS) のホワイトペーパー『 AWS でのキャリアグレードのモバイルパケットコアネットワーク 』および 『AWS を使用した 5G ネットワークの進化』で紹介されているように、AWS で 4G Evolved Packet Core(EPC) および 5G Core(5GC) を実装することで、スケーラビリティ、柔軟性、プログラム可能なオーケストレーション、基盤となるインフラストラクチャレイヤーの自動化などの大きな価値とメリットを得ることができます。 このブログ投稿では、オープンソースプロジェクト Open5gs を使用して 4G コアネットワークを構築するための実用的な実装ステップに焦点を当てます。

この記事は How to use AWS Secrets & Configuration Provider with your Kubernetes Secrets Store CSI driver を翻訳したものです。 AWS Secrets Manager を使用して、Amazon Elastic Kubernetes Service (Amazon EKS) の Kubernetes Pod で使用するために、AWS Secrets Manager からシークレットを安全に取得できるようになりました。AWS Secrets and Config Provider (ASCP) の登場により、Amazon EKS 上で動作するアプリケーションにシークレットを提供するために使用される業界標準の Kubernetes Secrets Store と Container Storage Interface (CSI) ドライバー の、使いやすいプラグインが利用できます。ASCP を使用して、ファイルシステムや etcd を介してシークレットをフェッチする従来の Kubernetes […]

Sanjay Garje と Vebhhav (Veb) Singh の共著あらゆる規模の企業が AWS クラウドに移行しています。エンタープライズチームのリーダーシップから、コストを抑えながら Amazon SageMaker に簡単にアクセスできる方法を模索しているという話を耳にします。これにより、データサイエンスを使った実験を促進し、新しいビジネスチャンスを開拓して現状を打破しています。このブログ記事では、Amazon SageMaker、AWS Service Catalog、および AWS Key Management Service (KMS) を使用してセルフサービスの安全なデータサイエンスを簡単に使えるようにする方法を紹介します。 このブログ記事では、AWS Service Catalog が事前設定された AWS KMS キーを使用して、複雑で不要な詳細をデータサイエンティストに公開することなく、ノートブックインスタンスにアタッチされている機械学習 (ML) ストレージボリュームで保存されているデータを暗号化する方法を説明します。ML ストレージボリュームの暗号化は、一元化されたセキュリティチームやインフラストラクチャチームが事前設定および調整した AWS Service Catalog 製品で行われます。Amazon SageMaker ノートブックインスタンス、トレーニングジョブ、またはエンドポイントを作成するときに、AWS KMS キー ID を指定できます。そのキーが、アタッチされた ML ストレージボリュームを暗号化します。トレーニングジョブ用の出力 Amazon S3 バケットを指定できます。トレーニングジョブも、AWS KMS で管理されるキーで暗号化されます。モデルのアーティファクトをその出力 Amazon S3 バケットに格納するための KMS キー ID を渡すことができます。 […]

お客様は、新しいビジネスユニットのオンボーディングやアプリケーションワークロードのセットアップを行うたびに、AWS Control Tower で新しいアカウントをプロビジョニングしています。場合によっては、組織はクラウドユーザー、開発者、およびデータサイエンティストに、新しいアカウントでセルフサービス標準化された安全なパターンとアーキテクチャをデプロイすることも求めます。以下にいくつか例を示します。 開発者またはクラウドエンジニアが、golden AMI から Amazon EC2 インスタンスを起動したいと考えています。 データサイエンティストは、承認済みの AMI とインスタンスタイプで Amazon EMR クラスターを起動したいと考えています。 データベース管理者は、新しくプロビジョニングされた AWS アカウントで承認済みの Amazon RDS データベースを起動する必要があります。 この記事では、AWS Control Tower の Account Factory を使用して新しい AWS アカウントをプロビジョニングする方法を示します。また、AWS Service Catalog を使用して、RDS データベースのポートフォリオなどのカスタム製品を新しいアカウントと共有する方法も示します。さらに、AWS Control Tower のガードレールを使用して新しいアカウントでガバナンスを実施する方法についても説明します。 このソリューションで使われる AWS のサービスは、以下のとおりです。 AWS Control Tower AWS Service Catalog AWS CloudFormation Amazon CloudWatch Amazon RDS AWS Organizations […]

多くのエンタープライズのお客様では、共通のセキュリティに関するデザインパターンやベストプラクティスとして、マルチアカウント戦略の導入を通じたアプリケーションの分離を行っています。かなりのお客様が、開発 (Dev) 、品質保証 (QA) 、そして実稼働 (Prod) といった開発ライフサイクル (SDLC) の各フェーズに合わせ、環境全体で完全な分離を実現するために、個別の AWS アカウントを作成する手法を選択しています。しかしながら、アカウント作成時点でアプリケーションからの要件が完全に理解できていない場合、必要なインフラストラクチャコンポーネントをプロビジョニングすることが困難になり得ます。加えて、作成されたアカウントが増えるに従い、それらの異なるカウント間でのインフラストラクチャのコンプライアンスと一貫性を実現するための手法を模索しなければなりません。 AWS Service Catalog は、こういった課題に対処するため役立ちます。これにより開発者は、どのような環境においても、インフラストラクチャコンポーネントを、素早く、安全かつ簡単にデプロイできるようになります。次の図は、このワークフローを示しています。ここでは、アプリケーションにおける Dev/QA/Prod 用の各アカウントが、実稼働および非実稼働向けのインフラストラクチャコンポーネントを共有するために、AWS Service Catalog が使用されています。 お客様の多くに、AWS Service Catalog を使用するメリットは「一枚のガラス」を通すようにインフラストラクチャがプロビジョニングできることである、と捉えていただいていますが、実はこれには、製品のデプロイを自動化する機能も備わっています。前出の図にあるワークフローでは、アプリケーションのアカウントで共有している各製品は、それぞれの継続的統合/継続的デリバリー (CI/CD) パイプラインから、直接デプロイすることが可能です。これにより、コードおよびインフラストラクチャの依存関係と、各チームに分散した個別コンポーネントの所有権とを、開発者が固く結びつけることができる環境が提供されます。 このモデルからは、次のように 2 つの主要なメリットが得られます。 中心チームは、承認されたインフラストラクチャのバージョンを定義することで、コンプライアンスと標準化を実施できるようになります。 アプリケーション所有者が、使用すべきインフラストラクチャコンポーネントを自身で選択できる、セルフサービス型の環境が提供されます。 次の図で、このプロセスをさらに詳細に説明しています。ここでは、インフラストラクチャの定義は Shared Services チームにより処理されます。このチームにより、アプリケーションアカウントとの間で共有する、ネットワークやコンピューティングベースのリソースに関するカタログが作成されます。アプリケーションの所有者には、各要件に最も適合するコンポーネントを決定する役割があり、各所有者は複数のバージョンをが共有できます。これらの製品は、アプリケーションの CI/CD プロセスの一環として、AWS CodePipeline などの AWS のサービスを使用してデプロイされます。この、インフラストラクチャのデプロイ手法には、セキュリティ上のメリットもあります。アプリケーションパイプラインのアクセス権限は、基盤となっている AWS のサービスではなく、最小権限を保証しながら AWS Service Catalog ポートフォリオに対し適用されるからです。 AWS Service Catalog アカウントポートフォリオの共有を活用する CI/CD パイプラインの自動構築は、次の GitHub レポジトリから Amazon […]

AWS Key Management Service (AWS KMS) が AWS KMS API エンドポイントに接続する際に使われる Transport Layer Security (TLS) 1.2 暗号化プロトコルにおいて新しいハイブリッド型のポスト量子暗号（耐量子暗号）鍵交換アルゴリズムをサポートするようになりました。これらの新しいハイブリッドポスト量子アルゴリズムは、古典的な鍵交換による実証済みのセキュリティと、標準化作業で評価中の新しいポスト量子鍵交換の潜在的な耐量子安全特性を組み合わせたものです。これらのアルゴリズムの中で最も高速なものは、古典的な TLS ハンドシェイクと比較して約 0.3 ミリ秒のオーバーヘッドがあります。追加された新しいポスト量子暗号鍵交換アルゴリズムは、Kyber のラウンド 2 バージョン、Bit Flipping Key Encapsulation（BIKE）、および Supersingular Isogeny Key Encapsulation（SIKE）です。標準化に参加している各組織は、米国国立標準技術研究所（NIST） のポスト量子暗号の標準化プロセスの一環として、アルゴリズムを NIST に提出しています。このプロセスは、複数年にわたる数ラウンドの評価にまたがり、2021 年以降も続く可能性があります。 以前のハイブリッド量子暗号 TLS に関するブログ投稿で、AWS KMS がラウンド 1 バージョンの BIKE と SIKE を備えたハイブリッドポスト量子暗号 TLS 1.2 をリリースしたことを発表しました。ラウンド 1 のポスト量子暗号 アルゴリズムは引き続き AWS KMS でサポートされていますが、ラウンド […]

多くのゲームでデータベースが不可欠の部分であることは周知の事実です。けれども、ゲーム開発者としては、データベースのエンジニアリングではなく、優れたゲームの構築にすべての時間と専門知識を捧げたいでしょう。 わかります。私も、データストレージについて考えるのではなく、コリジョンボリュームの修正、フレームレートの引き上げ、あるいは完璧な制御システムの作成に気をかけたいです。では、それを簡単に行いましょう。この記事では、AWS の高速で柔軟な NoSQL サービスである Amazon DynamoDB を使用して、ゲームにデータベースを追加するのがいかに簡単であるかを示します。 DynamoDB は、キーをデータに関連付ける非リレーショナルデータベースです。データベース、特にゲームでの使用に詳しくない場合は、ゲームでのデータベースの基本的な使用法と、リレーショナルデータベースと非リレーショナルデータベース (ときに SQL と NoSQL と呼ばれる) の違いについて説明したこの記事「素晴らしいゲームのためのマネージドデータベース」をご覧ください。 Dynamo DB テーブルの作成 DynamoDB は、NoSQL データベースですが、SQL データベースから借用した用語テーブルを使用します。この場合のテーブルは、実際にはデータベースに格納されるアイテムの主要な機能を定義したものにすぎません。 DynamoDB には、テーブルを識別するためのテーブルのプライマリキーが常にあり、このキーはデータベースに保存されているすべてのアイテムに対して一意である必要があります。 便利なヒントは、プライマリキーが複数の値のハッシュになる可能性があることです。したがって、単一の一意の属性がない場合は、異なる属性を組み合わせて一意の値を作成できます。たとえば、名前とバージョン番号を持つアイテムです。「broadsword」という名前のアイテムは 10 個あり、「version 1」のアイテムは 100 個ありますが、「broadsword version 1」は 1 個しかありません。 DynamoDB には、オプションで、アイテムをすばやく並べ替えることができるソートキーもあります。たとえば、プレイヤーのソートキーはプレイヤークラスであるかもしれません。これにより、ゲーム内のすべてのファイタークラスのリストを取得するクエリが高速化されることでしょう。データベース内のアイテムを一意に識別するための代替方法でするセカンダリキーを持つこともできます。 このデモでは、プレイヤーキャラクターの属性を表す非常にシンプルなオブジェクトを作成します。オブジェクトには一意のプレイヤー ID、プレイヤーレベル、強さと知力の 2 つの統計が含まれます。プレイヤー ID がプライマリキーになり、このデモ用のソートキーやセカンダリキーはありません。 注意: 自分で練習したい場合は、ソートキーとして機能するプレイヤークラスを追加できます。 DynamoDB テーブルを作成する手順は次のとおりです。 AWS コンソールを開きます。 DynamoDB を検索して選択します。 DyanamoDB コンソールのホームページから [テーブルの作成] を選択します。 […]

AWS Systems Managerを使うと、マネージドインスタンスへのパッケージデプロイの順序を制御できます。マネージドインスタンスとして管理できるものには、Amazon Elastic Compute Cloud（Amazon EC2）インスタンス、他のクラウド環境で稼働するVMを含む仮想マシン（VM）、そしてオンプレミスサーバーがあります。ハイブリッドインフラストラクチャの構成管理手順を自動化したいお客様もいらっしゃるでしょう。そのためには、特定のマネージドインスタンス上で特定のパッケージを順序立てた方法で実行し、インストール順序においてそれぞれのパッケージが干渉し合わないようにする必要があります。現在、Systems Manager Distributorパッケージを使用することで、マネージドインスタンスにソフトウェアパッケージを公開できます。ただし、それらが1回限りのインストール用に構成されている場合、パッケージの実行はマネージドインスタンスで同時に発生する可能性があります。