Amazon Web Services ブログ

本日より、アプリケーション ロードバランサー (ALB)はAWS Lambda functionをターゲットにすることをサポートします。ウェブサイトの構築やウェブアプリケーションをAWS Lambdaを使いサーバレスなコードとして作成、管理し、ウェブブラウザやクライアントからのリクエストに簡単なHTTP(S)フロントエンドを提供するように設定できます。

AWS App Meshは、AWS上のマイクロサービスアプリケーション間の通信を簡単に監視、制御できるサービスメッシュです。 Amazon Elastic Container Service (Amazon ECS)やAmazon Elastic Container Service for Kubernetes (Amazon EKS)、Amazon EC2上で稼働するKubernetesで動作するマイクロサービスとあわせてApp Meshを使用できます。 今日からApp Meshはpublic previewとして利用できます。数ヶ月後に、新しい機能とインテグレーションを追加する計画です。 なぜApp Meshなのか？ 多くのお客様はマイクロサービスアーキテクチャでアプリケーションを構成しており、アプリケーションを多数の、独立してデプロイされ、操作される多数の別々の小さなソフトウエア群に分割しています。各コンポーネントが需要に応じて個別にスケールすることにより、マイクロサービスはアプリケーションの可用性とスケーラビリティを向上させます。各マイクロサービスはAPIを通じて他のマイクロサービスと相互に作用します。

ソフトウェア開発者には好みの開発ツールというものがあります。パワフルなエディタを使う人もいれば、特定の言語やプラットフォームに最適化された統合開発環境（IDE）を使う人もいます。AWS Lambda のコンソールのエディタを使って、2014年に私は初めての AWS Lambda 関数を作りました。現在では、サーバーレス・アプリケーションをビルドしデプロイするためのツールの選択肢は豊富になりました。例えば、昨年 AWS Cloud9 がリリースされて AWS Lambda のコンソールのエディタ環境は大きく強化されました。.NET アプリケーションでは、 AWS Toolkit for Visual Studio と AWS Tools for Visual Studio Team Services を使う事ができます。 AWS Toolkits for PyCharm、IntelliJ（プレビュー）、そして Visual Studio Code（プレビュー） 今日、 AWS Toolkit for PyCharm の一般提供をお知らせします。また、 AWS Toolkits for IntelliJ と Visual Studio Code の開発者プレビューをお知らせします。これら（AWS Toolkits for IntelliJ と Visual Studio […]

私は2014年にアナウンスしたAWS Lambdaを発表した興奮を覚えています。4年の間でお客様は様々な異なるユースケースでLambda関数をご利用頂いています。 例をあげると iRobotはAWS Lambdaをロボット掃除機のroombaのコンピュートサービスとして利用しています、Fanne MaeはMonte Carloの100万をこえる抵当のシミュレーションとして利用、Bustleは彼らのデジタルコンテンツへの数百万のリクエストとして利用しています。本日、私は2つの新しい機能をご紹介します、これは今までよりサーバレスの開発を簡単にするものです： Lambda Layers, 複数の関数で共用されるコードやデータをセンタライズし管理するものです Lambda Runtime API, あなたが開発する、どんなプログラム言語や特定のバージョンでも簡単に利用できるようになるものです これら2つの機能は一緒に利用することができます。ランタイムはレイヤとして共有できるために、開発者はLambda関数を作成時にお好みの言語で利用することができます。

2015年、私たちはAWS Well-Architected フレームワークを発表し、私は”Are you Well-Architected?“と問いかけをしました。このフレームワークには、クラウドでのシステム設計する際の、5つの柱について設計原則とベストプラクティスが含まれています。

Werner VogelsのKeynoteで、AWS LambdaのアップデートやServerless関連のアップデートが発表されました。 Rubyサポート 従来のJava, Go, PowerShell, Node.js, C#, Pythonに加えて Ruby がサポートされました。 Custome Runtime Linuxで動作するあらゆる言語のランタイムを利用することができるようになりました。 Nested Applications using Serverless Application Repository ネストされたアプリケーションを使用すると、小さなアプリケーションコンポーネントからアプリケーションをまとめて、これらのネストされたアプリケーションを展開することができます。 敏捷性を向上させるために、コンポーネント、モジュール、および完全なアプリケーションをチームと共有することができます。 ALB Support for Lambda LambdaがALBとの連携をサポートしました。 LambdaをALBのターゲットとして登録できるようになり、これにより、既存のアーキテクチャをLambdaに簡単に移行することができます。 EC2、Fargate、およびLambdaを一括して使用するなど、ニーズに基づいてコンピューティングバックエンドを混在させることも可能となります。 Step Functions service integrations AWSの各サービスサーと連携するワークフローをコードの記述なしで作成することができるようになります。 Web Socket support for API Gateway API GatewayのWeb Socket対応予定が発表されました。 LambdaとAPI Gatewayで実行されるリアルタイムの双方向通信アプリケーションを構築することができるようになります。    

AWS Step Functions はアプリケーション開発者のためのフルマネージドなワークフローサービスです。各アクティビティの接続と整理を、信頼性があり繰り返し可能な形で、ビジネスロジックとワークフローロジックを分離しながら、高レベルの設計と作業で実現できます。ワークフロー（ステートマシンと言います）を設計、テストした後、スケーラブルにデプロイして10,000から100,000もの処理を独立かつ同時に実行することができます。Step Functions は各ワークフローの状態を追跡し、モニタリングやロギングもシンプルにします。詳しくは 「サーバーレスワークフローを作成する」 のチュートリアルをお試しください。

Amazon Managed Streaming for Kafka(MSK)のプレビューが発表になりました。 Amazon MSK ストリーミングデータを処理するApache Kafkaは、リアルタイムのストリーミングデータパイプラインとアプリケーションを構築するためのオープンソースのプラットフォームです。Amazon MSKは、Apache Kafka APIを使用してデータ・レイクを作成したり、データベースとの間で変更をストリーミングしたり、マシンの学習および分析アプリケーションを強化することができるフルマネージドサービスです。 Apache Kafkaクラスターは、実動環境でセットアップ、スケール、および管理が難しく、、サーバーのプロビジョニング、手動によるApache Kafkaの構成、障害が発生したサーバーの置き換え、サーバーのパッチとアップグレードの調整、高可用性のためのクラスターの設計、データの永続的な保管と保護、負荷変動をサポートするスケーリングイベントの計画などが必要になります。 KafkaのAmazon Managed Streamingは、Apache Kafkaのインフラストラクチャ管理の専門知識を必要とせずに、Apache Kafkaで本番アプリケーションを構築して実行することを容易にします。つまり、インフラストラクチャの管理に要する時間を短縮し、アプリケーションを構築する時間を短縮できます。 Amazon MSKは、ネットワーク分離、Amazon VPC、コントロールプレーンAPI認証用のAWS IAM、および残りの暗号化など、Apache Kafkaクラスターの複数レベルのセキュリティーを提供します。Amazon MSKの暗号化サポートは、AWS Key Management Service  （KMS）と統合されてい  ます。 – プロダクトマーケティング エバンジェリスト 亀田  

By: Alexandr Moroz, Sr. Product Manager, Amazon Route 53; Madhuri Peri, Sr. IoT Architect, AWS Professional Services; Aaron Molitor, Sr. Infrastructure Architect, AWS Professional Services; and Sarma Palli, Sr. DevOps Architect, AWS Professional Services AWS Cloud Mapを利用するとクラウドをマッピングすることができます。Amazon S3のバケットやAmazon DynamoDBのテーブル、Amazon SQSのキュー Amazon EC2やAmazon ECS、Amazon EKSやAWS Lambda上で構成されたカスタムクラウドサービスの様な任意のリソースに対しても分かりやすい名前を定義できます。AWS SDKと認証されたAPIクエリを使って分かりやすい名前にてリソースの場所やメタデータを検出することができます。 デプロイメントステージやバージョンの様なカスタム属性によって、リソースをさらにフィルターし、検出することができます。

アプリケーションをマイクロサービス(多数の別れたサービスがそれぞれ1つのジョブを実行する)として構成するお客様が増えています。マイクロサービスによりお客様は、多くの場合で反復的かつ、より素早いデプロイを可能になります。これらのマイクロサービスをベースとしたモダンなアプリケーションの多くは、様々な種類のクラウドリソースを利用して構成され、動的に変更されるインフラストラクチャ上にデプロイされます。これまでは、アプリケーションリソースの場所を管理するために設定ファイルを利用する必要がありました。しかし、マイクロサービスをベースとしたアプリケーションにおける依存関係は簡単に管理するには、複雑すぎる様になります。加えて、多数のアプリケーションは動的にスケールし、トラフィックにあわせて変更されるコンテナを利用して構成されていています。その様な構成はアプリケーションの応答性を向上させますが、新しい問題をもたらします。- 現在、アプリケーションのコンポーネントはその動作時にアップストリームサービスを検出し、接続する必要があります。この動的に変更されるインフラストラクチャーおよびマイクロサービスにおける接続性に関する問題は、共通してサービスディスカバリーによって解決されます。