Category: Compute

AWSでVMwareとのグローバルアライアンスリードを務めるRima Olingerによる記事です。 アマゾン ウェブ サービス (AWS)とVMwareは、VMware Cloud on AWSの共同設計ソリューションを通じて、お客様に代わってイノベーションを続けています。

EC2スポットインスタンススペシャリスト ソリューションアーキテクトの滝口です。2020年11月11日にオンラインで開催された「秋のスポットインスタンス祭り」セミナーでは、100名を超える聴衆の方々にご参加いただき、AWSのソリューションアーキテクトによる技術解説に加え、スポットインスタンスを効果的に活用されている2社のお客様の具体的な事例をご紹介いただきました。 本記事では、お客様のご登壇資料を含む当日資料をご紹介し、また参加者の皆様からいただいた当日のQ&Aの一部をご紹介します。 当日アジェンダと資料 13:00 ～ 13:45　自動スケールから始める EC2 スポットインスタンス 講師：滝口　開資（アマゾン ウェブ サービス ジャパン株式会社　ソリューション アーキテクト） 概要：みなさまのシステム、自動スケール機能はお使いでしょうか。クラウドに移行したものの、EC2インスタンスはずっと立ち上げっぱなし。負荷の高いタイミングでも台数固定。そしてEC2の費用は慢性的に高止まり。こんな課題を抱えていらっしゃるみなさまに向けて、まず前半ではスケールする大規模処理での例としてWebサービス、機械学習、データ分析のワークロードを取り上げ、活用できる技術スタックの選定方針を紹介しました。 そして後半では、EC2インスタンスの自動スケールの仕組み、そしてそこにスポットインスタンスを組み合わせてコスト最適化を狙う方法をわかりやすくお伝えしました。 自動スケールから始める EC2 スポットインスタンス 13:45 ～ 14:15　実例から学ぶAWS Batch x スポットインスタンスによる大規模バッチ処理 講師：宮本 大輔（アマゾン ウェブ サービス ジャパン株式会社　ソリューション アーキテクト） 概要：クラウドでは必要な時に必要な量の計算リソースを起動して処理を行うことができるため、HPC (High Performance Computing) やゲノム解析、大量の動画像の処理といった用途に適しています。そしてこのような大規模バッチ処理をコスト効率よく行うためにはスポットインスタンスの活用が重要なポイントとなります。本セッションでは、大規模バッチ処理に対してスポットインスタンスを適用する際に考慮しなければいけないことや、注意すべきポイントについて、AWS Batchを活用した実例を交えてご紹介いたしました。 実例から学ぶAWS Batch x スポットインスタンスによる大規模バッチ処理 14:15 ～ 14:45　スポットインスタンス/インスタンスフリートを活用した Amazon EMR のコスト最適化 講師：川村　誠（アマゾン ウェブ サービス ジャパン株式会社　ソリューション アーキテクト） 概要：Amazon EMR はスポットインスタンスとインスタンスフリートを活用することで、コストを最適化することができます。直近のサービスアップデートでそれらの活用がより簡単に運用可能となりました。本セッションでは […]

10 月 28 日に、「SaaS+サーバーレス/EventBridge」で開発迅速化、運用作業削減 〜ビジネスにアジリティーをもたらす「SaaS + サーバーレス」〜 と題したセミナーを開催し、6社の SaaS パートナー様にご登壇いただきました。登壇いただいたパートナー様の SaaS アプリケーションはすべて　Amazon EventBridge に対応いただいています。 EventBridge は、サービスとサービスの間をつなぐためのバスとして機能し、様々なアプリケーションや AWS サービスと連携できます。EventBridge に対応いただいているSaaS アプリケーションは、簡単かつセキュアに、イベントソースとして AWS のサーバーレスサービス群と連携させることができます。 本セミナーでは、各社の SaaS のご紹介とともに、EventBridge に対応することで SaaS パートナーとして何が良いのか、SaaS を利用されるお客様にとってどんなメリットがあるのか、といったポイントでご説明いただきました。アンケート結果でも、SaaS との連携手法として EventBridge という選択肢があることを知る機会になった、とか、なかなか聞けないパートナー様目線での EventBridge の効能がわかってよかったなどのご意見がありました。 本記事では、改めて、ご登壇いただいたパートナー様のセッション動画および公開資料をご紹介します。EventBridge ってなんぞや? という方は、AWS セッションとしてご説明した「サーバーレスを取り巻く状況と EventBridge の概要」や Game Server Services 丹羽様のセッション資料/動画を先にご覧いただくことをお勧めします。その上で、各 SaaS パートナー様のセッション内容をご覧いただくと、SaaS + EventBridge で何ができるのかをご理解いただけるかと思います。また、次の BlackBelt 資料も参考になるでしょう。 EventBridge に関連した Black Belt […]

本記事は、EC2プロダクトサービスチームのDeepthi ChelupatiとChad Schmutzerによる寄稿です。 本日より、Amazon EC2 Auto Scaling のキャパシティリバランシング機能を提供するようになりました。これは、Auto Scaling グループで Amazon EC2 スポットインスタンスのライフサイクルをプロアクティブに管理するための新機能です。キャパシティリバランシングは、最も余裕のある空きキャパシティを自動的に選択する capacity-optimized 配分戦略 (英語記事)と、複数のアベイラビリティーゾーンにまたがって複数のインスタンスタイプを活用できるミックスインスタンスポリシー機能を補完する位置付けの機能です。キャパシティリバランシングは、スポットインスタンスが Amazon EC2 サービスによって中断される前に、 Auto Scaling グループのスポットインスタンスを自動的に置き換えます。これにより、お使いの Auto Scaling グループの可用性をより一層高めることができます。 スポットインスタンスの事前置き換えを実現するため、キャパシティリバランシングは EC2 サービスの新機能である、 EC2 インスタンスのリバランス通知を活用します。これは、スポットインスタンスが中断のリスクが高まった際に送信されるシグナルです。リバランス通知は、これまで提供してきた 2 分前のスポットインスタンス中断通知よりも早く提供されることが期待されるため、来たる中断に備え、ワークロードをプロアクティブにリバランスする機会を提供します。 EC2 Auto Scaling のキャパシティリバランシングは、スポットインスタンスのライフサイクルを踏まえ、その時点で必要な希望容量を維持するためのシームレスで自動化された仕組みを提供します。これには、リバランス通知の監視、また中断のリスクが高い場合の代替キャパシティーの事前起動、さらに必要に応じて Elastic Load Balancing からのデタッチや、設定されたライフサイクルフックの実行が含まれます。この記事では、スポットインスタンスを中心としたワークロードに対して、EC2 Auto Scaling でキャパシティリバランシングを使用して Auto Scaling グループを管理する方法の概要を説明し、お使いの環境でキャパシティリバランシングを活用するためのユースケースの例を紹介します。 EC2 Auto Scaling と スポットインスタンス — これまでのおはなし さてここで、スポットインスタンスが何であるか、また EC2 […]

AWSはLINE Fukuoka株式会社様による「LINE SMART CITY GovTechプログラム」への支援を通じて、行政サービスのデジタル化を推進していきます。 LINE SMART CITY GovTechプログラムは、福岡市LINE公式アカウントの機能開発の知見を活かして開発した、全国の自治体が汎用的に活用できるLINE公式アカウントの機能のソースコードを無償提供するという取り組みです。このソースコードはAWS環境での導入を想定して開発されており、自治体様はAWS環境でそのまま利用することができます。 加えて、AWSパブリックセクターでは、自治体様および開発会社（SIer）様がクラウド導入において検討が必要となる自治体特有のセキュリティ面の整理や、AWSサービスについての最適な利用方法に関わる技術サポートについて、お問い合わせ窓口をご用意いたしました。 益々注目が高まる行政サービスのデジタル化と国民の利便性の向上に寄与できる取り組みとして、AWSのパブリックセクターで培ったノウハウと経験を提供していきます。 ❖行政のデジタル・トランスフォーメーションを促進 「LINE SMART CITY GovTechプログラム」では、自治体が住民接点のサービスを向上していくうえでニーズのある４つの機能を、自治体のLINE公式アカウントへ追加する機能が提供されます。 １）セグメント配信　市民の属性に合わせた情報発信 ２）申請/アンケート　市民からの申請や情報提供を受け付ける機能 ３）FAQチャットボット ４）統計情報の管理、権限設定 セグメント配信、申請・レポート、チャットボット等は、自治体様が導入意欲を持たれていましたが、予算の兼ね合い、モバイルアプリの浸透、開発実装できるベンダが地域に居ない等々の理由により導入が先送りする現状がありました。「LINE SMART CITY GovTechプログラム」は8600万以上のユーザ数（MAU）を持つLINEを活用することでLINE公式アカウントを通して住民への展開を加速することが可能です。提供するソースコードはAWS上へ改変することなく導入可能であり、全国のAWSのパートナー企業（APNパートナ）や開発企業と共に導入のご支援を行います。 ❖ サーバーレスのサービスで構成 LINE Fukuoka株式会社様のプレスリリースにあります通り、ソースコードはAWS上で開発されており、「セキュリティと柔軟性を兼ね備えたスピーディーなシステム構築において強みを持つアマゾン ウェブ サービス(以下、AWS)を用いることで、必要となる環境構築を迅速に構築いただけるように開発しております。」と言及いただいております。 アーキテクチャはAWS Serverless Application Model を活用したサービス構成で組まれており、クラウドの特性を活かした柔軟で持続性を考慮したスケーラブルで運用面の負担を軽減するアーキテクチャを採用いただいています。サーバレスのメリットとして以下を挙げていただいています。 ・環境構築の容易さ ・運⽤コストが限りなく少ない ・トラフィックの急増に耐えるスケーラビリティ ・セキュリティに対する信頼性 ・幅広いエンジニアが対応できる技術 ❖ 自治体が求めるクラウド安全性とは なぜ自治体様にとってもクラウドが必要か、セキュリティ面でご安心できるのか、下記に記載します。 なぜクラウド？自治体においても迅速性が重要課題に：新型コロナ禍での社会経済活動を支援するため、自治体においてもかつてない程迅速性が求められています。従来のように一年かけて検討することも重要ですが限られた時間で思考錯誤を繰り返しながらまずは新しいサービスをローンチし改善を繰り返していくことが重要と認識され始めています。例えば東京都の感染症サイトはCode for Japanが受託し開発したソースコードをGitHubで公開しました。結果同様の課題を持つ自治体が地域コミュニティやGovTech企業と共に各地域毎の感染症サイトをクラウド上へ展開しました。自治体共通の課題をクラウドを活用して迅速に課題解決した素晴らしい事例です。「LINE SMART CITY GovTechプログラム」についてもAWS上へ展開していくことで企画開発期間を短縮し迅速にLINEを活用した住民サービスを開始することが可能と言えます。また、クラウドを活用することで最新技術を活用したデータ分析、AI・機械学習の利活用による付加価値が見込まれます。   AWSのセキュリティ面：AWSでは責任共有モデルによりクラウド利⽤者とクラウド事業者の役割分担が明確に定義されています。利⽤者はデータの所有権と統制を保持しており、例えば適切なアクセス制御、暗号化を活用した統制の実装によりAWSを含む第三者によるアクセスからの保護を実現できます。自治体のクラウド選定にあたっては、「政府機関等の情報セキュリティ対策のための統一基準群」、「地方公共団体における情報セキュリティポリシーに関するガイドライン」を満たすクラウドサービスを選定することが安全性を高めるために求められます。AWSは以下のような自治体が遵守すべき事項に対応しており安心してご利用頂くことが可能です。 ・情報資産を管理するデータセンターの物理的所在地を日本国内とすること ・クラウドサービス事業者のカスタマーアグリーメントの準拠法を日本法に変更し、同契約に関するあらゆる紛争に関する第一審裁判所を東京地方裁判所に変更可能であること ・情報資産の所有がクラウドサービス事業者に移管されるものではないこと。したがって、自治体が要求する任意の時点で情報資産を他の環境に移管させることができること。 ・クラウドサービス事業者は、ISO/IEC27017 […]

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートであるJulian Woodによる寄稿です。 AWS Lambdaは、Lambda Extensionsのプレビューを発表しました。Lambda Extensionsは、お好みのモニタリング、オブザーバビリティ、セキュリティ、ガバナンス用ツールとLambdaとの統合を簡単にする新しい方法です。このブログでは、Lambda Extensionsがどのように動作するのか、どのように使い始められるか、さらに、AWS Lambda Ready パートナーの提供する現在利用できるextensionについて説明します。 お客様が既に使用しているツール群とLambdaを統合をしたいというリクエストは数多く寄せられており、Extensionsはその問題を解決するサポートをしてくれます。お客様からは、自分の使いたいツールとLambdaをつなげるために、追加の作業や設定を行うことが必要だという指摘が以前からありました。さらに、ログエージェントなどの長時間実行されるプロセスが必要なツールをLambda上で実行するのは、かなり難しいことでした。 Extensionsは、ツールがLambda環境と深く統合するための新しい方法です。複雑なインストレーションや設定は必要なく、お客様のアプリケーションポートフォリオ上にある好きなツールを簡単に使えるようになります。例えば以下のようなユースケースでExtensionsを使用できます： 関数呼び出し前、呼び出し中、呼び出し後の診断情報をキャプチャーする コード変更なしにコードの計測を自動的に行う 関数の呼び出し前に設定やシークレットを取得する 関数とは別のプロセス上で実行されている堅牢なセキュリティエージェントを通して、関数のアクティビティを検知・アラートする ExtensionsはAWS、AWS Lambda Readyパートナー、またオープンソースプロジェクトから使用することができます。本日時点（2020年10月8日 PDT）で AppDynamics、Check Point、Datadog、Dynatrace、Spsagon、HashiCorp、Lumigo、New Relic、Thundra、Splunk SignalFX、AWS AppConfig、Amazon CloudWatch Lambda Insightsのextensionが利用可能です。 どのように自分用のextensionを作成するかや、Lambdaのライフサイクルの変化についてのディープダイブについては、関連記事である“AWS Lambda Extensions (プレビュー) を構築する“をご覧ください。 概要 Lambda Extensionsは、複雑なインストレーションや構成管理を必要とせずに、簡単にお客様が現在使用しているツールにつなぐことができるよう設計されています。ExtensionをAWSマネジメントコンソールやAWS Command Line Interface (AWS CLI)経由でLambdaレイヤーとしてデプロイすることができます。AWS CloudFormationやAWS Serverless Application Model (AWS SAM)、Serverless Framework、Terraformなどのinfrastructure as codeツールからも使用できます。 また、Epsagon、New Relic、Lumigo、Thundraからの統合をStackeryを使って自動化できます。 […]

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートであるJulian Woodによる寄稿です。 AWS Lambda は使い慣れたモニタリング、オブザーバビリティ、セキュリティ、ガバナンスツールをお客様の Lambda と簡単に統合するための新たな手段として、Lambda Extensions のプレビューを発表しました。各種ツールは、Extensions を利用することでより深く Lambda 実行環境を制御し、そのライフサイクルに関与することができます。この単純化によって現在お客様がご利用中のツールを、より簡単に、アプリケーション・ポートフォリオに対して横断的に適用することが可能となります。 本稿では Lambda Extensions の仕組みや Lambda のライフサイクルの変化、および Extension を構築する方法について解説します。お客様の関数で Extensions を利用する方法については、関連するブログ “AWS Lambda Extentions（プレビュー）のご紹介” をご覧ください。 Extensions は新たに導入された Lambda Extensions API を利用して構築します。各種ツールは Extensions API を利用することで、関数の初期化、呼び出し、終了に対してより強くコントロールすることができます。この API は、 Lambda にカスタムランタイムを導入する際に利用される、既存の Lambda ランタイムインターフェースの上に構築されています。 お客様はアプリケーションパフォーマンス監視や機密管理、構成管理、脆弱性検知等のユースケースのためにAWSやAWS Lambda Ready パートナー、オープンソースプロジェクトによって提供される extensions を利用することができます。また自ら extensions を構築することで、Extensions API を使用してお客様固有のツールを統合することも可能です。 2020年10月08日時点で […]

先日 (2020/10/21) 開催しました AWS Black Belt Online Seminar「Amazon VPC 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201021 AWS Black Belt Online Seminar Amazon VPC AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. オンプレミス設計ではいくつかのネットワークを使い分けていました。1. サービス用NW 2. バッチ用NW 3. 管理用NW。Linux であれば bond0, bond1, bond2 と複数のデバイスを割り当てていました。分けていた理由は NW ACL 設定を分けるため (バッチ用 NW と管理用NWのみ SSH 許可 かつ SSH デーモンが Listen するのも対象I/Fのみ、など)　それぞれ N/W 帯域を使い切ってしまったときに影響を局所化するため、でした。Amazon VPC では、どのように設計するのがよいのか教えていただけますか？オンプレミス比較でのドキュメント、ホワイトペーパー、ブログなどあれば紹介いただけると助かります。 A. クラウドコンピューティングのためのアーキテクチャ・ベストプラクティス はいかがでしょうか。オンプレミスの考え方をそのまま踏襲してしまうと余計な手間やコストを生んでしまうので Well-Architectedフレームワークを利用してよりよいアーキテクチャを作ることをおすすめいたします。 […]

今回はクラウドにおける安全なデータの廃棄において取り上げた安全なデータ廃棄をどのように実践するかをお伝えします。

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1：サーバーレス LAMP スタックの紹介 パート2：リレーショナルデータベース パート3：Webサーバーの置き換え パート4：サーバーレス Laravel アプリの構築 パート5：CDK コンストラクトライブラリ この投稿では、マイクロサービスを使用してサーバーレス PHP アプリケーションを構築する方法をご理解いただけます。これまでご紹介してきた MVC フレームワークを利用した単一の Lambda 関数によるスケーラブルな Web ホスティングから、分離されたマイクロサービスモデルに移行する方法を示します。なお、このブログ投稿に付随するコード例は、この GitHub リポジトリにあります。 MVC アーキテクチャパターン 従来の LAMP スタックでは、多くの場合、Model-View-Controller（MVC）アーキテクチャを使って実装しています。これは、アプリケーションロジックをモデル、ビュー、およびコントローラの3つの部分に分離して実装する、確立された手法です。 モデル：この部分はアプリケーションのデータを管理する役割を果たします。その役割は、データベースから生データを取得したり、コントローラからユーザー入力を受け取ることです。 ビュー：このコンポーネントは表示に焦点を当てています。モデルから受け取ったデータをユーザーに提示します。ユーザーからの応答が認識され、コントローラコンポーネントに送信されます。 コントローラ：この部分はアプリケーションロジックを担当します。ユーザー入力に応答し、データモデルオブジェクトに対して相互作用を実行します。 データ、ロジック、およびプレゼンテーション層を分離するという MVC の原則により、1つの層での変更が他の層に与える影響を最小限に抑えることが可能です。これにより、開発プロセスがスピードアップし、レイアウトの更新、ビジネスルールの変更、および新機能の追加が容易になります。コンポーネント化によって、再利用とリファクタリングの適用性があがり、同時/並行開発がしやすくなります。 サーバーレス LAMP スタック サーバーレス LAMP スタックアーキテクチャについては、この投稿で説明しています。そこでは Webアプリケーションが 2つのコンポーネントに分割されています。アプリケーションにおける MVC フレームワークの役割をはたす単一の AWS Lambda 関数と、各応答を同期的に返す […]