Amazon Web Services ブログ

Category: Developer Tools

Solutions Design diagram explaining how the solution is structured

Selenium, AWS Lambda, AWS Fargate, AWS Developer Tools を使ったサーバーレスなUIテスト

(この記事は、 Serverless UI testing using Selenium, AWS Lambda, AWS Fargate, and AWS Developer Tools を翻訳したものです。) 以前、Using AWS CodePipeline, AWS CodeBuild, and AWS Lambda for Serverless Automated UI Testing (日本語版 ) を公開してから、Chrome headless とFirefox headless が各ブラウザでネイティブにサポートされるようになったことで、事態は大きく変わりました。 AWS Lambda は今やコンテナイメージをサポートし、 AWS Step Functions はLambda と統合された Map state のサポートを追加し、AWS Fargate は完全にサーバーレスのテクノロジを利用した、UIテストを可能にしました。

Read More

AWS Cloud Development Kit v2 開発者プレビューのお知らせ

AWS Cloud Development Kit (AWS CDK) v2が開発者プレビューとして、TypeScript、Python、Java、C#、Go言語で利用できるようになりました。AWS CDKは、使い慣れたプログラミング言語を使ってクラウドアプリケーションのリソースをモデル化し、プロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。AWS CDKを使用すると、インフラストラクチャをコードとして定義し、AWS CloudFormationを通じてプロビジョニングすることができます。AWS CDKは、実績のあるデフォルト値で事前に設定された高レベルなコンポーネントを提供しているため、専門家でなくてもクラウドアプリケーションを構築することができます。また、組織の要件を組み込んだ独自のカスタムコンポーネントを構成して共有することができるため、チームが新しいプロジェクトを迅速に開始することができます。 2019年7月には、TypeScriptとPython向けのAWS CDK v1の一般提供を発表しました。それ以降、JavaとC#の追加言語のサポートをリリースし、Go言語バインディングの開発者プレビューをリリースしました。今回はv2のプレビューリリースを発表します。このリリースによりAWS CDKをより簡単に利用できるようになり、また今後のバージョンアップに対応することがより容易になります。 AWS CDK v1アプリケーションの最新マイナーバージョンからv2への移行は、比較的簡単です。まずAWSアカウントで再度ブートストラップ (cdk bootstrap) をする必要がありますが、これは各リージョンで一度だけの作業です。ほとんどのプロジェクトでは、インポート文を更新し、合成(synth) し、デプロイするだけで済みます。リソースに若干の変更があるかもしれませんが、リソースの作り直しが必要になるようなことはありません。 この記事では、AWS CDK v1とv2の間の変更点をご紹介します。

Read More

AWS CodeCommit が大阪リージョンでご利用いただけます

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、シニアエバンジェリストの亀田です。 AWS CodeCommit が大阪リージョンでご利用いただけるようになりましたのでお知らせいたします。 AWS CodeCommit CodeCommit はプライベートな Git ベースのリポジトリをセキュアにホストする完全マネージド型サービスです。お客様は独自のソースコントロールシステムを稼働させる必要がなくなり、インフラストラクチャのスケーリングに関する不安要素を払しょくできます。ソースコードからバイナリまですべてのものを1ファイサイズあたり最大2GB まで、セキュアに保存でます。すべての Git コマンドをサポートし、既存の Git ツールとの連動がサポートされています。使い慣れた開発環境のプラグイン、継続的統合/継続的デリバリーシステム、グラフィカルクライアントを CodeCommit と合わせて引き続き使用することができます。 CodeCommit は、通信中および保管中のファイルを AWS Key Management Service (KMS) との連携により自動的に暗号化し、AWS Identity and Access Management (IAM) と統合されているため、ユーザー固有のアクセス許可をリポジトリに簡単に設定することができます。プルリクエスト、分岐、マージを介して、チームメイトとのコードによるコラボレーションを支援します。コードレビューとフィードバックを含むワークフローの実装や、特定の分岐を変更できるユーザーの管理も簡単です。 Subversion、Perforce などのその他のリポジトリに関しては、まず Git インポーターを使用して Git リポジトリに移行いただく必要があります。詳しくは以下の手順をご覧ください。

Read More

Amazon CodeGuru Reviewer のアップデート: 最大 90% 値下げとなる新しい予測可能な料金モデル、Python サポートが一般利用可能に

Amazon CodeGuru は、機械学習と自動化された推論を活用した推奨事項により、コードレビューの自動化とコード品質の向上を支援します。 CodeGuru Reviewer を使用すると、検出しにくい潜在的な欠陥やバグを検出し、 CodeGuru Profiler によってライブデータに基づいてアプリケーションのパフォーマンスを微調整することができます。このサービスは 2020 年 6 月から一般公開されています。CodeGuru の使用開始方法については、こちらをご覧ください。 ここ数か月で多くのお客様と協力しながら、 セキュリティ検出器、プレビューでの Python サポート、メモリプロファイリングを導入し、お客様がコード品質を向上させ、デベロッパーの時間を節約するのを支援しています。また、料金設定や対象言語の範囲など、さまざまな分野に関するご意見もいただきました。こうしたフィードバックに対応し、より簡単に組織内で大規模に Amazon CodeGuru を採用できるようにしました。 本日、CodeGuru Reviewer の 2 つの主要なアップデートを発表いたします。 リポジトリのサイズに基づいて月額料金を低く固定し、最大 90% の値下げとなる、まったく新しい、見積もることが簡単な料金モデルになっています。 Python サポートが一般利用可能 (GA)となりました。推奨範囲が広く、Python 検出器に関連する 4 つの更新が行われています。 CodeGuru Reviewer の新しい予測可能な料金 CodeGuru Reviewer を使用すると、GitHub、GitHub Enterprise、AWS CodeCommit、Bitbucket に保存されているリポジトリのフルスキャンを実行できます。また、プルリクエストを送信するたびに、 CodeGuru Reviewer は新しいコードレビューを開始し、コメントの形式で推奨事項と改善を提案します。 以前の料金体系は、1 か月あたりの分析コード行数 (LoC) に基づいており、100 LoC あたり 0.75 USD […]

Read More

AWS CDKでエンタープライズアプリケーションを開発する

エンタープライズのお客様は、ガバナンスやコンプライアンス・品質管理のために Infrastructure as Code (IaC)を標準化しなければならない場合があります。さらに、IaCのライブラリやそのアップデートを中央集権的に管理しなければならない場合もあるでしょう。それらを実現するため、この記事では AWS Cloud Development Kit (AWS CDK) を利用してIaCのパターンを定義する方法や、AWS CodeArtifactを利用してIaCの更新リリースを統制する方法を紹介します。

Read More

分散型環境における AWS Service Catalog を使用したインフラストラクチャデリバリーの標準化

多くのエンタープライズのお客様では、共通のセキュリティに関するデザインパターンやベストプラクティスとして、マルチアカウント戦略の導入を通じたアプリケーションの分離を行っています。かなりのお客様が、開発 (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 […]

Read More

AWS Service Catalog を使用しての、Amazon ECS 継続的デリバリー用の自動設計図の共有

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

Read More

AWS CDKでクラウドアプリケーションを開発するためのベストプラクティス

この記事では、AWS Cloud Development Kit (AWS CDK) を中心とした、大規模なチームで複雑なクラウドアプリケーションの開発を組織化するための戦略について説明します。AWS CDK では、開発者や管理者は、TypeScript、Python、Java、C#などの使い慣れたプログラミング言語を使ってクラウドアプリケーションを定義することができます。アプリケーションは、Stage、Stack、Constructに整理されており、ランタイムロジック (AWS Lambda コードやコンテナ化されたサービスなど) と、Amazon Simple Storage Service (Amazon S3) バケット、Amazon Relational Database Service (Amazon RDS) データベース、ネットワークなどのインフラストラクチャコンポーネントの両方において、モジュール化された設計手法を可能にしています。 この記事では、AWS CDKの基本的なコンセプトに関する簡単なチュートリアルではなく、より実践的な内容について説明します。ローカルでコードを書きテストする方法や、本番環境や様々なステージングアカウントにデプロイする方法、そしてチームのアプリを整理して、より大きな組織で活用する方法について説明します。 AWS CDKを初めてご利用になる方は、AWS CDK Intro Workshop から始めることを強くお勧めします。この記事では、いくつかの高度なトピックを扱っていますが、基礎を把握しておくと良いでしょう。詳細については、AWS CDKリファレンスドキュメントとGitHub リポジトリにある aws-cdk-examples  のサンプルコードを参照してください。

Read More

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

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

Read More

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

先日 (2021/01/26) 開催しました AWS Black Belt Online Seminar「AWS CodeDeploy」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20210126 AWS Black Belt Online Seminar AWS CodeDeploy AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. cloudfront がELBの先にあった場合、blue/Green のデプロイした場合に、キャッシュはどのようになるのでしょうか? A. CloudFront のキャッシュ保持期間が経過するまでキャッシュは更新されません。画像などキャッシュ対象のコンテンツを配置するディレクトリにバージョンを付与する等して、それを参照することでデプロイバージョンに応じたコンテンツを取得することが可能です。 Amazon CloudFront – 既存のコンテンツと CloudFront ディストリビューションを更新する Q. AutoScaling グループへデプロイした場合、そのグループの起動テンプレートで指定している AMI との整合性はどうなりますか?(codedeploy で新しいのがデプロイされても、スケーリングで立ちあがる新しいインスタンスは、古いAMIを参照してしまうのではないでしょうか? A. スケールアウト時に追加されたインスタンスに対して最新リビジョンがデプロイされますので、起動テンプレートで指定している AMI とはアプリケーションのバージョンが異なる状態となります。AMI ではなくリビジョンについてのご質問の場合、既存インスタンスとスケールアウトによって追加されたインスタンスに異なるリビジョンがデプロイされる可能性があります。回避策はこちら「AWS CodeDeploy – 展開中のスケールアップイベント」のドキュメントをご覧ください。 Q. Deploy について、CloudFormation と CodeDeploy どちらかで行うのが良いのか指標などありますでしょうか?例えとしましては、Lambda を […]

Read More