Category: Compute

業界を取り巻く環境 世界的なパンデミックが日本にも影を落としている中、ストリーミングを使ったライブイベントの配信が驚異的な伸びを示しています。2020年の早い段階から、大規模なイベントや対面集会が次々に中止に追い込まれました。オリンピックが延期され、プロスポーツは無観客となりました。企業においても入社式や集合教育、株主総会といったものがソーシャルディスタンスの導入により大きな影響を受けています。この流れの中、ライブイベント配信を支える企業にはこれまで無縁だったビジネスを含め、様々な業界から無数の依頼が舞い込んでおり、その全てに対応するには非常に難しい環境にあります。

AWS のパートナーソリューションアーキテクト、Kishore Vinjam Dynatrace の戦略的パートナーイネーブルメント＆エバンジェリズム担当ディレクター、Andreas Grabner 氏 クラウド運用またはシステム管理で作業するエンジニアは、多くの場合、パフォーマンスモニタリングツールで検出された問題を修正するために手動でスクリプトを更新する必要があります。 これには、プロセスの再起動、リソースのクリーンアップ、メモリの停止、および CPU 使用率に関する問題などがあります。このような問題は頻繁に発生し、貴重な時間が取られてしまいます。 この記事では、お客様がどう Dynatrace、AWS Lambda、および AWS Service Catalog を使用して、ワークフローを構築し、Dynatrace AI で検出された問題に対して必要なインシデント対応アクションを開始するかを説明します。 Dynatrace AI は、エンドユーザーが、基礎となるシステムリソースが原因で実際のユーザーエクスペリエンス、サービスレベルアグリーメント (SLA)、またはサービスの可用性から影響を受けたときに、問題を検出して通知をトリガーします。基礎となるリソースに起因する問題には、ディスクがいっぱいである、設定の変更が不適切、負荷が増加している、または依存するサービスの問題などがあります。 AWS Service Catalog を使用すると、AWS での使用が承認されているサービスのカタログを作成および管理でき、Lambda を使用すると、サーバーをプロビジョニングまたは管理せずにコードを実行できます。 Dynatrace は、AWS パートナーネットワーク (APN) のアドバンストテクノロジーパートナーで、Migration、DevOps、Containers の AWS コンピテンシーを持っています。今日の複雑な IT 環境で成功し、明日や将来も成功し続けるには、Dynatrace などの AWS コンピテンシーパートナーと連携することがスマートな一手 (The Next Smart) です。 AWS コンピテンシープログラムでは、お客様の成功事例を紹介したり、特定のソリューション領域やセグメントで高い専門性を示したりしたトップの APN パートナーを確認、検査、精査しています。 AWS Service Catalog のアーティファクトの自動調整 AWS […]

AWS クラウドに移行する予定の会社の移行プロジェクトに関与している場合は、移行の準備、ポートフォリオの発見、計画、設計など、さまざまな段階を経ることでしょう。ほとんどの場合、これらの段階の後に正念場を迎え、物理ベース、仮想ベース、またはクラウドベースのインフラストラクチャワークロードの AWS への移行を開始します。AWS のお客様は、CloudEndure (現在は AWS の会社) などのツールを使用して、アプリケーションの移行、災害復旧や AWS へのレガシーインフラストラクチャのバックアップを自動化します。移行中にお客様が直面する課題の 1 つに、サーバーを管理して、数百または数千の AWS アカウントで構成される階層的なアカウント構造に移動することがあります。このブログ記事では、新しい CloudEndure 移行プロジェクトのセットアップを自動化する方法と、お使いの環境で新しいアカウントを販売するたびに「アカウント自動販売機」を使用してこのプロセスを自動化する方法を学びます。 はじめに CloudEndure は、AWS への大規模な移行と障害復旧のデプロイを簡素化、迅速化、自動化するのに役立ちます。継続的なデータレプリケーションはバックグラウンドで行われ、アプリケーションの中断やパフォーマンスへの影響はありません。これにより、データがリアルタイムで同期され、カットオーバー/フェイルオーバーウィンドウが最小限に抑えられます。カットオーバー/フェイルオーバーが開始されると、CloudEndure は高度に自動化されたマシン変換とオーケストレーションプロセスを実行します。これにより、最も複雑なアプリケーションやデータベースでも、互換性の問題なく、最小限の IT スキルで AWS でネイティブに実行できます。AWS Marketplace から CloudEndure をデプロイできます。 このアカウントの自動販売機を作成するには、AWS Service Catalog、AWS Lambda、AWS Organizations などのネイティブの AWS のサービスを追加で使用します。また、CloudEndure との API 統合を使用して、アカウントの作成後に新しいプロジェクトをセットアップします。さらに、移行をサポートするために、販売したアカウントで AWS Direct Connect、Amazon Kinesis Data Firehose、Amazon S3 Transfer Acceleration などの追加の AWS のサービスを設定して、この参考用のサンプルソリューションを拡張できます。 このソリューションのサービス このソリューションで使用するサービスの簡単なレビューを次に示します。 […]

組織が AWS のサービスの使用を拡大するにつれて、ビジネスプロセスの分離またはセキュリティ、コンプライアンス、請求のために複数の AWS アカウントを作成する必要性についてしばしば語られます。私たちが仕事をしている多くのお客様は、各ビジネスユニットで別々の AWS アカウントを使用しているため、組織のさまざまなニーズに対応できます。複数のアカウントを作成すると、運用上の問題が簡素化され、セキュリティやリソースの分離、トラブルの影響の到達範囲の縮小、請求の簡素化などの利点が得られますが、ベースライン設定の作成、ブートストラップ、設定に時間がかかります。お客様は、アカウントの作成とブートストラップをスケーラブルかつ効率的な方法で管理して、定義済みのベースラインを使用して新しいアカウントを作成し、ガバナンスガードレールを配置したいと考えています。最も重要なことは、時間とリソースを節約するために、お客様が自動化を望んでいることです。このブログ記事では、一般的なガードレールを自動化し、デフォルトユーザーの作成、カスタムネットワークの設定、AWS のサービスのキュレーションセットを使用した製品の既存の AWS 環境へのプロビジョニングなどのタスクを設定することにより、アカウントの作成と設定を自動化する方法を紹介します。このブログは、前のブログ記事 AWS Organizations を使用してエンドツーエンドのアカウント作成を自動化する方法で説明した実装を拡張します。 このブログ記事で説明されている AWS のサービス: AWS Organizations は、複数の AWS アカウントのポリシーベースの管理を提供します。AWS Organizations を使用すると、アカウントのグループを作成し、アカウント作成を自動化し、それらのグループのポリシーを適用および管理できます。 AWS Service Catalog は、AWS での使用が承認されているサービスのカタログを作成および管理できます。 AWS CloudFormation は、クラウド環境のすべてのインフラストラクチャリソースを記述およびプロビジョニングするための共通言語を提供します。AWS CloudFormation を使用すると、シンプルなテキストファイルを使用して、すべてのリージョンとアカウントにわたってアプリケーションに必要なすべてのリソースを自動化された安全な方法でモデリングおよびプロビジョニングできます。 AWS Lambda を使用すると、サーバーのプロビジョニングや管理を必要とせずにコードの実行が可能になります。料金は消費したコンピューティングの時間分だけを支払います。コードが実行されていない場合は無料です。 このブログ記事で使用されている用語: ルートアカウント – アカウントビルダーが AWS Service Catalog 製品として起動される単一の AWS アカウント。新しく構築されるすべてのアカウントは、このアカウントで実行されている AWS Organizations のルートの下に作成されます。 ベースラインテンプレート – このテンプレートには、新しく作成されたアカウントの AWS Service Catalog ポートフォリオで AWS […]

このブログは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 […]

VMware Cloud on AWSはVMwareのSoftware-Defined Data Center (SDDC)技術をAWSのグローバルインフラストラクチャ上で提供するためVMwareとAWSが共同開発したソリューションです。 様々なストレージ要件のワークロードが存在する場合、利用可能なストレージオプションの種類を把握し、異なる条件下でそれらをどう使っていくことが最適であるかを理解することが重要です。 VMware Cloud on AWSは複数のストレージサービスと統合されており、VMware vSphereワークロードに対して選択肢と柔軟性を提供しています。しかしながら各サービスは特定のシナリオに最適化されており、ワークロード全体に対して最適な単一のアプローチというものはありません。正しいサービスを選択するには、まずVMware vSphereワークロードのストレージ要件やパフォーマンスの統計データを理解しなければいけません。それを踏まえた上で、お客様のワークロードに適したコスト、可用性、パフォーマンス要件を満たすストレージを計画、実装することができます。

AWSでSpecialist Partner Solutions Architectを務めるKiran Reid、Sr TAM (MNG) を務めるSudha Thillai Govindarajan、Principal Partner Solutions Architectを務めるWen Yuによる記事です。 さまざまな業界や業種のお客様が、本番ワークロードにVMware Cloud on AWSを採用しています。 高可用性要件で実行したいワークロードがある場合、利用可能なさまざまなアーキテクチャパターンと構成オプションを理解することが重要です。 本稿では、VMware Cloud on AWSを活用するお客様の耐障害性設計に関する主な考慮事項と責任について説明します。

Edit in the Cloudシリーズの第1回目では、AWS上で様々な編集シナリオの想定モデルを実現するための基礎知識を説明しました。今回はいよいよGitHubのサンプルをデプロイする段階に入ります。このステップ バイステップガイドでは、AWS上で編集ホスト、ストレージをデプロイし、接続する方法を詳しく説明します。このテンプレートによりユーザーはAmazon Elastic Compute Cloud (Amazon EC2) 上に編集環境を構築することができます。加えて、Amazon FSx for Windows ファイルサーバーはEC2インスタンスからストレージとして利用し、メディアアセットの共有リポジトリとして活用することができます。また、このテンプレートには、Teradici for Federated Loginと連携したAWS Directory Servicesが含まれており、シームレスな編集体験を可能にしています。では早速テンプレートを利用して環境を構築していきましょう。まずご自身のAWSアカウントを利用して、AWSマネジメントコンソールにログインしたら次のAWS CloudFormationデプロイメントテンプレートを使用します。本テンプレートは現在、US-East-1とUS-West-2で提供しています。

この記事は、AWS Dev Tech のスペシャリスト SA である Mahmoud ElZayet が執筆しました  現代的なアプリケーション開発プロセスは、各組織がスピードや品質を継続的に向上することを可能にしています。このような革新的なカルチャーにおいては、小型の自律的なチームに、アプリケーションの全ライフサイクルがゆだねられます。ただ、こういった敏速かつ自律的なチームは、製品デリバリーを加速する一方で、コンプライアンスや品質保証、およびコードデプロイのためのインフラストラクチャに対するコストを生じさせます。 標準化したツールやアプリケーションリリース用コードを用いることで、チーム間でベストプラクティスを共有でき、冗長的なコードを削減し、オンボーディングを加速し、一貫性のあるガバナンスを作り上げながらリソースのオーバープロビジョニングを減らせます。   概要 今回の記事では、標準化され自動化されたデプロイ設計図を、AWS Service Catalog を使用して提供する方法をご紹介していきます。これは、製品チームによる Amazon ECS でのアプリケーションリリースワークフローの改善と迅速化に役立ちます。ここでの手順を実施していただくと、お客様の製品チームが ECS 上でコンテナ化されたアプリケーションをリリースするために使用できる、サンプル設計図が作成できます。この設計図のコンセプトは、サーバーレスや Amazon EC2 をベースとするデプロイなど、他のテクノロジーにも適用が可能です。 本稿で提供するサンプルテンプレートやスクリプトはデモ用に用意したものなので、実稼働環境でそのまま使用するには適しません。これらのリソースになじんだ後で、手元にあるツールや、チームのスキル、そして適用すべき規格や規制をすべて考慮しながら、実稼働環境向けにカスタマイズしたバージョンを作成してください。   前提条件 ここでのソリューションには、次に挙げる各リソースが必要です。 AWS アカウント での管理者アクセス権限 AWS CLI   サンプルシナリオ Example Corp という企業では、アプリケーションやサービスを AWS 上で開発するために、いくつかの製品チームを抱えています。同社内の各チームは、ECS 上の AWS Fargate で管理するコンテナ化したアプリケーションのデプロイに関心を示しています。ここでは、Example Corp. における主幹ツール管理チームとして、各チームが Fargate で迅速にアプリケーションをリリースできることを目指します。さらに、すべてのベストプラクティスやガバナンス要件を、各チームが準拠することも保証していきます。 事情を単純にするために、製品チームはすでに構成済みであり、サービスのデプロイ用に AWS のアカウントを共有しながら、同じドメイン、アプリケーション、もしくはプロジェクトで作業をしていると想定します。この 1 つのアカウントを通じ、チーム全体が同じ ECS […]

この投稿は、スタートアップソリューションアーキテクトのRudolf Potucekによって書かれました。 Amazon API Gateway の REST API は、2016 年からバイナリデータをサポートしています。2020年3月に GA した Amason API Gateway のHTTP API を使用 すると、バイナリメディアタイプとテキストメディアタイプの両方をより簡単に操作できます。新しいペイロード形式バージョンをサポートし、リクエストおよびレスポンス形式に基づいてエンコーディングを推測します。この投稿では、HTTP API と AWS Lambda を使用して、テキストまたは画像のいずれかを受け入れて返すAPIを構築する方法を示します。Amazon API Gatewayの base64 エンコーディングは、AWS Lambda でのテキストとバイナリデータの処理を統合します。バイナリデータと非バイナリデータ（テキストデータ）は、JSON オブジェクトの文字列として Lambda 関数に渡されます。HTTP API の Lambda 統合では、リクエストで渡されたcontent-type ヘッダーに基づいてエンコードの必要性を自動的に推測します。