Category: Compute

本投稿は AWS サーバーレス アプリケーションのプリンシパルデベロッパーアドボケートであるChris Munnsによる寄稿です。 元の投稿からの更新情報： 2019年11月28日（PST）：  次のリージョンに対して、元の投稿に記載されている改善を完全に展開しました：中東（バーレーン）。 2019年11月25日（PST）：次のリージョン、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中央）、EU（ロンドン）、EU（ストックホルム）、およびアジア太平洋（香港）に対して、これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。 2019年11月6日（PST）：次のリージョン、米国西部（北カリフォルニア）、EU（アイルランド）、EU（パリ）、アジア太平洋（ムンバイ）、アジア太平洋（ソウル）、アジア太平洋（シンガポール）、アジア太平洋（シドニー）、南アメリカ（サンパウロ）に対して、これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。 2019年9月27日（PST）：米国東部（オハイオ）、欧州（フランクフルト）、およびアジア太平洋（東京）の地域へ完全に展開しました。これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。 既知の問題（2019年10月4日（PST）に更新）： HashiCorp Terraformを使用している場合、サブネット、セキュリティグループ、VPCなどのVPCリソースは、この新しいモデルでのENIの動作方法の変更により破棄に失敗する可能性があります。この問題を解決するための手順と、詳細についてはこちらをご覧ください。 2019年9月3日（PST）の元の投稿： AWS Lambda 関数が Amazon VPC ネットワークでどのように機能するかが大幅に改善されたことをお知らせします。 2019年9月3日（PST）のローンチ機能により、関数の起動パフォーマンスが劇的に改善され、Elastic Network Interface がより効率的に使用されるようになります。 これらの改善は、すべての既存および新しい VPC 接続の関数に追加費用なしで展開されています。 ロールアウトは 2019年9月3日（PST）から始まり、すべてのリージョンで今後数か月にわたって徐々に展開されます。 Lambda は2016年2月に初めて VPC をサポートし、AWS Direct Connect リンクを使用して VPC またはオンプレミスシステムのリソースにアクセスできるようになりました。 それ以来、お客様が VPC 接続を広く使用して、さまざまなサービスにアクセスしているのを見てきました。 Amazon RDS などのリレーショナルデータベース Redis 用 Amazon ElastiCache または Amazon Elasticsearch Service などのデータストア Amazon EC2 または […]

先日 (2019/8/20) 開催しました AWS Black Belt Online Seminar「Serverless モニタリング」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190820 AWS Black Belt Online Seminar Serverless モニタリング from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. トレースは、Lambda以外にEC2やECSのアプリなどでも利用可能なのでしょうか？ A. Amazon EC2: インスタンスを起動するときに、ユーザーデータのスクリプトを使用して自動的にデーモンを実行することができます。詳細は、AWS公式サイトを参照ください。 Amazon ECS: Amazon ECS で、X-Ray デーモンを実行する Docker イメージを作成し、それを Docker イメージリポジトリにアップロードして、Amazon ECS クラスターにデプロイできます。タスク定義ファイルでポートマッピングとネットワークモード設定を使用すると、アプリケーションがデーモンコンテナと通信できるようになります。詳細は、AWS公式サイトを参照ください。 — 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。 【AWS Innovate Online Conference】 […]

先日 (2019/08/14) 開催しました AWS Black Belt Online Seminar「AWS Serverless Application Model」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20190814 AWS Black Belt Online Seminar AWS Serverless Application Model from Amazon Web Services Japan   AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. AWS SAM CLI 自体を Docker コンテナの中で実行することは可能でしょうか？ A. Docker コンテナの中で実行することも可能です。ただし、Lambda 関数のローカル実行や、コンテナを利用したビルドを行う場合、コンテナの中でコンテナを起動する形になるため、たとえば docker コマンドの実行時に privileged フラグを付与するといった、いわゆる docker in docker の構成でコンテナを起動するための手続きは必要になりますので、ご留意いただければと思います。 Q. 自動で生成されるLambdaの単体テストはどのように実施できるのでしょうか？ A. SAM […]

スケーラブルなアプリケーションを構築するときは、マイクロサービスベースのアプリケーションアーキテクチャを使うのが標準となっています。AWS が提供する Amazon DocumentDB (MongoDB 互換) を利用すると、こうしたタイプのアプリケーションの作成がこれまでよりもさらに容易になります。MongoDB のワークロードをサポートしている、この高速でスケーラブル、かつ可用性に優れたフルマネージド型のドキュメントデータベースサービスでは、ご自分のコードを用いてアプリケーションをデプロイするだけです。 Amazon DocumentDB でのワークロードの実行、管理、スケーリングには、現在使用している MongoDB 向けのアプリケーションコード、ドライバー、ツールをそのまま使用できます。これにより、基盤となるインフラストラクチャの管理に煩わされることなく、向上したパフォーマンス、スケーラビリティ、アベイラビリティを活用できます。 この記事では、2019 年 4 月 26 日の映画「アベンジャーズ／エンドゲーム」公開時に主要なイベントや観客の反応を確認するアプリケーションをどう構築するか、その方法について解説します。AWS Lambda アプリケーションを設定および接続し、Amazon DocumentDB にクエリを実行する際のベストプラクティスを学べます。AWS Secrets Manager と Amazon API Gateway も使用します。 概要 買い物サイトやオンラインパブリケーションは、コンテンツやカタログの管理システムに依存しながら顧客にサービスを提供しています。こうしたシステムは、ユーザーレビュー、画像、評価、製品情報、コメントに迅速かつ確実にアクセスできる必要があります。Amazon DocumentDB が提供している柔軟なドキュメントモデル、データタイプ、インデックス作成、そして、強力かつ複雑なクエリを実行できる能力は、すばやく直感的な、コンテンツの保存や発見を可能にします。 この記事のユースケースでは、Global Database of Events, Language and Tone (GDELT) の公開されているデータセットをサンプルとして使用します。GDELT Project は、「世界中のあらゆる国のほぼ全地域における、100 を超える言語の放送、出版、ウェブニュースを監視し、人、場所、組織、テーマ、情報源、反応、回数、引用、画像、イベントを特定しています」 アプリケーションの構築には、次の AWS のサービスを使用します。 Lambda – サーバーをプロビジョンまたは管理しなくても、コードの実行を可能にするサービスです。料金は、コンピューティング使用時間に対してのみ発生します。コードが実行されていなければ無料です。 API Gateway – […]

Microsoft SQL Server 2017 は、Windows と Linux 間の Always On 可用性グループをサポートして、高可用性 (HA) なしで読み取りスケールのワークロードを作成します。残念ながら、そのクロスプラットフォーム設定を管理できるクラスター化されたソリューションがないため、Windows と Linux の間で HA を実現することはできません。 Always On 可用性グループで HA を使用するには、Windows Server Failover Cluster (WSFC) または Pacemaker on Linux の使用を検討してください。このソリューションは、SQL Server on Windows から Linux へ、そしてその逆への移行パス、または手動フェイルオーバーを使用した災害復旧に適しています。 前提条件 開始する前に、以下がインストールされていることを確認してください。 Windows Server 2012 R2 または 2016 と SQL Server 2017 Enterprise Edition SQL Server 2017 […]

先日 (2019/7/31) 開催しました AWS Black Belt Online Seminar「Amazon ECS Deep Dive」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190731 Black Belt Online Seminar Amazon ECS Deep Dive from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. Fargateのタスクスケジューリングにおいても、AWS Secrets Managerを利用できるのでしょうか？（以前検証した時、タスクスケジューリングではAWS Secrets Managerを利用できなかったため） A. はい、ご利用いただけます。ご利用の際考慮する点としては、タスクに付与されたタスク実行ロールにて AWS Secrets Manager や KMS の操作が許可されている必要があります。詳細はこちらをご覧ください。 Q. 複数ECSサービスを起動する場合、同数のALBが必要になるのでしょうか？Targetgroupの数だけでよい認識です。 A ご指摘ありがとうございます。ご指摘通りの構成をご利用いただけます。ウェビナー中に紹介したような複数 ALB 構成は、例えば各マイクロサービスにおける各チームの独立性をAWSリソースのレベルで担保したいような場合に効果的です。設計に応じて使い分けくださいませ。 Q. ECS Agentがコントロールプレーン、コンテナホストのDockerdへのどのような制御を行っているか網羅的に理解できる資料はございませんか？ A 現時点で紹介できる資料はございません。具体的な動きを確認したい場合、GitHubにて公開されているAmazon ECS […]

本投稿は Wesley Pettit と Michael Hausenblas による寄稿を翻訳したものです AWS はビルダーのために作られています。ビルダーは常に最適化の方法を模索し、それはアプリケーションのロギングにも当てはまります。全てのログの重要性が同等ということはありません。あるログはリアルタイムの分析を必要とし、他のログは必要となった時に分析が行えるよう単に長期間保管しておくことを必要としたります。それ故に AWS とパートナーが提供する様々なストレージや分析のツールに容易にログをルーティングできることが重要です。 そこで私たちは Fluent Bit をサポートし、コンテナ化されたアプリケーションから AWS やパートナーのログ保存ソリューション、ログ分析ソリューションへのログストリーム向けに、容易に利用可能な拡張ポイントを作成できるようにします。新しくリリースしたAWSコンテナイメージ向けの Fluent Bit プラグインを用いて、ログを Amazon CloudWatch と Amazon Kinesis Data Firehose の送信先 (Amazon S3、Amazon Elasticsearch Service、Amazon Redshift を含みます)へルーティングすることが可能です。 本投稿では、Fluent Bit プラグインのECS、EKS 両クラスタでの動作をご紹介いたします。ツール自体に慣れていない場合は、こちらの記事（basics of Fluentd and the Kinesis Firehose）にあるチュートリアルを確認いただくと参考になるかもしれません。よろしければ AWS containers roadmap の関連するイシュー #10 と #66 もご参照ください。

本投稿は AWS コンテナサービスのプリンシパルディベロッパーアドボケートである Massimo Re Ferreによる寄稿です クラウドのセキュリティはAWSの最優先事項であり、コンテナチームの取り組みがその証でもあります。およそ1か月前、私たちは AWS Secrets Manager や AWS Systems Manager パラメータストアと、AWS Fargate タスクの統合機能を発表しました。 これにより Fargate のお客様は、ご自身のタスク定義から秘密情報を安全に、パラメータを透過的に利用することができます。 この記事では、秘密情報を確実に保護しつつ Secrets Manager と Fargate の統合を利用する方法の例を紹介します。 概要 AWS は複数の重要なセキュリティ上の基準を以って Fargate を高度にセキュアに設計しました。その 1つは、各Fargate タスクはそれぞれに分離境界があり、下層のカーネル、CPUリソース、メモリリソース、またはElastic Network Interface（ENI）を他のタスクと共有していないところです。 セキュリティに重点を置くもう 1 つの領域は、Amazon VPC ネットワーキング統合です。これにより、ネットワーキングの観点から Amazon EC2 インスタンスを保護する手法で Fargate タスクを保護できます。 この発表は、責任共有モデルの観点でも重要です。例えば、AWSのプラットフォーム上でソリューションを構築して実行するようなDevOpsチームは、アプリケーションコードの実行時に秘密情報、パスワード、機密パラメータをセキュアに管理する適切な仕組みや機能を必要とします。そして、プラットフォームの機能によって彼ら/彼女らがまさにそのようなことを可能な限り簡単に実行できるようにすることが私たちの役割なのです。 私たちは、時に一部のユーザーがセキュリティ面をトレードオフとして俊敏性を得るために、ソースコードに AWS 認証情報を埋め込んだままパブリックリポジトリにプッシュしたり、プライベートに格納された設定ファイルに平文でパスワードを埋め込んでいるのを見てきました。私たちは、さまざまなAWSサービスを利用している開発者が IAM ロールを Fargate タスクに割り当てることができるようし、AWS 認証情報を透過的に取り扱えるようにすることで、この課題を解決しました。 これはネイティブな […]

本投稿は Nathan Taber と Michael Hausenblas による寄稿を翻訳したものです re:Invent 2017で、私たちは Amazon Elastic Container Service for Kubernetes(Amazon EKS) を紹介しました。当時発表した次の tenets(信条) は、現在に至るまで引き続き確かなものであると考えています。

増え続けるデータを処理し、新しいデータソースを取り込むことは、多くの組織にとって大きな課題となっています。  多くの場合、AWS のお客様は接続中のさまざまなデバイスやセンサーからメッセージを受け取っていますが、それらを詳しく分析する前に、効率的に取り込み、処理する必要があります。  結果として、あらゆる種類のデータが行き着くソリューションが Amazon S3 となるのは当然と言えるでしょう。  ただし、データが Amazon S3 に格納される方法によって、ダウンストリームデータ処理の効率とコストに大きな違いが生じる可能性があります。  具体的に言うと、Apache Spark では少数の大きなファイルを処理する場合に比べて、小さいファイルを数多く処理すると、ファイル操作に負担がかかります。  これらのファイルにはそれぞれ、メタデータ情報のオープン、読み込み、クローズの処理に数ミリ秒のオーバーヘッドがあります。これらのファイルを数多くファイル操作すると、このオーバーヘッドのために処理が遅くなります。このブログ投稿では、Amazon Kinesis Data Firehose を使用して、Amazon S3 に配信する多数の小さいメッセージを大きいメッセージにマージする方法を説明しています。  この結果、Spark を実行している Amazon EMR の処理が高速化します。 Amazon Kinesis Data Streams と同様、Kinesis Data Firehose は最大で 1 MB のメッセージサイズを受信できます。  単一のメッセージが 1 MB を超える場合は、ストリームに配置する前に圧縮できます。  ただし量が多い場合、メッセージのファイルサイズが 1 MB 以下だと通常小さすぎます。  正しいファイルサイズというものはありませんが、多くのデータセットでは 1 MB を指定するとファイルの数とファイル操作が多すぎることになるでしょう。 この投稿では、Amazon S3 にある Apache Spark を使用して、圧縮ファイルを読み込む方法についても説明します。この圧縮ファイルには適切なファイル名拡張子がなく、parquet […]