Amazon Web Services ブログ

Category: AWS Lambda

モダンアプリケーション開発ホワイトペーパー(日本語改定版)が公開されました

皆さん、こんにちは! モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー(日本語版)がAWSホワイトペーパーサイトで公開されましたので、その内容を紹介させて頂きます。このホワイトペーパーは、以前こちらのブログで紹介させて頂いたModern Application Development on AWS(英語版)の日本語版になります。   ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、「AWS モダンアプリケーション開発 – AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン」(日本語版)というタイトルの51ページのドキュメントで、 はじめに モダンアプリケーション開発 モダンアプリケーションの設計パターン AWSでのCI/CD まとめ の各章から構成されています。各章の簡単なご紹介は下記の通りです。

Read More

ECS、S3、Athena、Lambda、AWS Data Exchange を使用して、詳細な暗号通貨市場データを収集して配布する

これは Floating Point Group によるゲスト投稿です。彼らの言葉を借りると、「Floating Point Group は、機関投資家レベルの取引サービスを暗号通貨の世界にもたらすことをその使命としています」。 デジタル資産の取引向けに設計された金融インフラの必要性と需要はどれだけあるのかは、はっきりしないかもしれません。コインとトークンは、通貨、商品、株式、債券などの従来の資産に効果的にネイティブに相対するデジタル商品であると、広く受け止められています。この説明はよく、専門家が仮想空間内のさまざまなプロジェクトの価値提案を伝えようとするときに、力強く簡潔に伝えるために繰り返し用いられています (「ビットコインは、アルゴリズムで制御された改ざん防止の財務ポリシーが備わった、単なる通貨です」、または、「イーサリアムは、ガソリンのような金融商品です。それを使って、グローバルコンピューターの計算作業に支払うことができます」)。驚くことではありませんが、FPG である質問をよく耳にします。「暗号通貨が専用の金融サービスであることを保証するのに特別な点は何かありますか? なぜすでに解決された問題の解決策が必要なのですか」 実際、これらの資産とそれを取り巻く広範な公共の利益には、まったく前例がありません。ネットワークトランザクションのイミュータブルな記録として機能する分散型台帳テクノロジー。合理的なアクターを経済的に動機付けてネットワークのセキュリティを維持するためのプルーフオブワークアルゴリズムの巧妙な使用 (プルーフオブワークの概念は少なくとも 1993 年まで遡りますが、このテクノロジーが広く採用される可能性が示されたのは、ビットコインが登場してからです)。人的ミスや強要などの場合に固有の法的課題を引き起こす不可逆的な取引の性質。自己管理の不安定性 (サードパーティの保管ソリューションには、信頼を高める実績はありません)。これらの資産を分類することと、最終的に IRS、SEC、CFTC のようなエンティティによって調整する必要がある通貨交換を仲裁することの両方の困難を伴う規制上の不確実性。これらはすべて、非常に新しく、非常に特異なものです。24 時間取引が行える市場の規模は定期的に 1,000 億 USD を超えており、この記事では特にこれらの資産の取引に関連する問題に焦点を当てます。 確かに、仮想通貨取引は、ウェブフォーラムでビットコインを交換し始め、国際取引所間で 10% の価格スプレッドが確認されて以来、間違いなく成熟してきました。しかし、まだ長い道のりがあります。 機関投資家のために取り組むことを目指す上で抱える主な問題点の 1 つに、流動性 (またはより正確には、流動性の欠如) の問題があります。簡単に言えば、暗号通貨の売買は多くの異なる取引の場 (取引所) で行われ、流動性 (特定の価格で特定の量の資産を売買するオファー) は、新しい取引所が出現するにつれて断片化し続けています。100 ビットコインを購入しようとしているとしましょう。あなたは売りたい人から買う必要があります。最良の (最も安い) オファーを取得するにつれ、残りのオファーはどんどん高価になります。注文を完了するまでに (この例では、100 ビットコインをすべて購入するまでに)、たとえば注文の最初のビットコインに支払った価格よりも平均的にはるかに高い価格を支払うことになったかもしれません。この現象はスリッページと呼ばれています。スリッページを最小限に抑える 1 つの簡単な方法は、オファーの検索範囲を広げることです。そのため、1 つの取引所のオファーを見るのではなく、数百の取引所のオファーを見るのです。このプロセスは、従来スマートオーダールーティング (SOR) と呼ばれ、当社が提供するコアサービスの 1 つです。当社の SOR サービスにより、トレーダーは数十の取引所の流動性を積極的に監視することで、システムが複数の取引所で利用できる最高のオファーとマッチする注文を簡単に送信できます。 最良の価格を求めて大量注文を出すことは、かなり直感的で広く適用できる概念です。株式の約 75% が SOR を介して売買されています。けれども、暗号化市場向けのこのようなサービスの価値は特に顕著です。既存の取引所が行き詰まる中、新しい取引所が人気を博すという永続的なサイクルのため、取引所全体で流動性が絶え間なく断片化されています。けれどもトレーダーは、取引所に依存しない考え方を持つ傾向があります。ある特定量の資産にとって最良の価格を見つけることにのみ関心があるのです。 […]

Read More

Kinesis と DynamoDB をイベントソースにする際の AWS Lambda の新しいスケーリング管理

AWS Lambda は、Amazon Kinesis Data Streams と Amazon DynamoDB ストリームのイベントソースで利用可能な、新しいスケーリングパラメータを導入しました。Parallelization Factor は、各シャードにおける Lambda 関数呼び出しの同時実行数を増やす設定を可能にします。このパラメータは、デフォルトでは 1 です。これによって、処理されるレコードの順序を保証しながら、シャード数を過大にスケールすることなく、より高速なストリーム処理が可能になります。

Read More

【開催報告】ビルシリーズ@住友不動産六本木グランドタワー 第1回

みなさんこんにちは!アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉です。 11月21日に「ビルシリーズ@六本木一丁目住友不動産六本木グランドタワー 第1回」を開催いたしました。今回は「初めてのサーバレスWebアプリケーションハンズオン」を実施しました。こちら「ビルシリーズとは?」とお思いの方も多いかと思いますので、開催報告と合わせてご説明いたします。 「ビルシリーズ」とは? このイベントは、日頃AWSをご利用いただいているお客様に、AWSからの情報発信はもちろん、同じビルに拠点を構えるお客様同士の活発な意見交換と交流の場を定期的に作ることを目的としたものです(同じビルなので移動が楽!)。 今回、住友不動産六本木グランドタワーのFringe81様、BASE様、エブリー様、ディップ様で同じようなニーズがあり、このようなビル単位でのイベントを開催する運びとなりました。場所はFringe81様の素敵な大会場をお借りいたしました。Fringe81様ありがとうございました。 来月には住友不動産麻布十番ビルでも開催を予定しており、今後もこのようなビル単位で交流ができるようなイベントを開催していきたいと考えております。 当日の様子 当日は約40人のお客様にお越しいただき、イベントは終始盛り上がりを見せておりました。   まずはAWSJ 植本より、今回のビルシリーズの趣旨などを説明いたしました。   次に、AWSJ 木村より「サーバレスのご紹介 – ユースケースパターンを切り口に」というタイトルで、AWSのサーバレスプラットフォームについてご紹介いたしました。   続けてAWSJ 木村より「初めてのWebアプリケーションハンズオン」を実施いたしました。   ハンズオンの終了後、ご参加いただいた皆様と共に、簡単な懇親会を開催いたしました。   今回、AWSJより、アカウントマネージャー植本、藤田、細木、ソリューションアーキテクト上原、石見、小宮、木村がビルシリーズをサポートいたしました。こちらはソリューションアーキテクトの集合写真です。 貴社担当のアカウントマネージャから「ビルシリーズ」のお誘いがあるかもしれませんが、是非ご検討いただければと思います。それでは、次回のビルシリーズでお会いしましょう!   著者について 木村 公哉(Kimura, Koya) 香川県出身のソリューションアーキテクトです。好きなサービスはAWS AmplifyとAWS Lambda、Amazon Kinesisです。好きな食べ物はうどんです。   上原 誠(Uehara, Makoto) アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。

Read More

Amazon SNS, Amazon SQS, AWS Lambda のデッドレターキューによる耐久性のあるサーバーレスアプリケーション設計

この投稿は Otavio Ferreira, Sr Manager, SNS の寄稿によるものです 郵便システムにおいて、デッドレターキューは配信不能な郵便物を取り扱うための施設です。pub/sub メッセージングモデルにおけるデッドレターキュー (DLQ: dead-letter-queue) は、トピックに対して発行されたメッセージがサブスクライブしているエンドポイントに配信できなかった場合に、そのメッセージを送ることができるキューを表します。 Amazon SNS による DLQ サポートによって、アプリケーションはメッセージ配信における各種故障モードに対する、さらなる耐久力と回復力を持つことが可能になりました。 メッセージの配信失敗と再試行を理解する Amazon SNSがサブスクライブされたエンドポイントにアクセス出来ない場合、メッセージの配信は失敗します。このような状況は大きく2つの原因によって引き起こされます: クライアントエラー。ここでクライアント (メッセージ送信者) は SNS となります。 サーバーエラー。ここではサーバーは、例えば Amazon SQS や AWS Lambda のようにサブスクリプションのエンドポイント (メッセージ受信者) をホストするシステムとなります。 クライアントエラー クライアントエラーは、 SNS の保持しているメタデータが最新ではない場合に発生します。クライアントエラーの発生するよくある原因としては、エンドポイントの所有者がエンドポイントを削除した場合が挙げられます。例えば SNS に紐付いたサブスクリプションを削除することなく、SNS トピックにサブスクライブした SQS キューを削除してしまったような場合です。やはりよくある別の例としては、エンドポイントに適用されたポリシーに対して、SNS がメッセージを配信することを阻害するような変更を加えてしまった場合が挙げられます。 これらのエラーは、クライアントがメッセージの配信を試みたにもかかわらず、クライアントの視点からエンドポイントがアクセス不能となっていることが原因で発生するため、クライアントエラーとして取り扱われます。SNS はクライアントエラーの結果として失敗したメッセージの配信を再試行することはありません。 サーバーエラー サーバーエラーは、サブスクライブしているエンドポイントを実行しているサーバーが利用できないか、または SNS からの有効なリクエストを処理できなかったことを表す例外応答を返した場合に発生します。 サーバーエラーが発生した場合、SNSは線形、指数的のいずれかのバックオフ機能に基づいて配信を再試行します。SQS や Lambda 上で実行される AWS […]

Read More

新しいサーバーレスアプリ作成機能で CI/CD も作成した、その後…

本記事は「新しいサーバーレスアプリ作成機能で CI/CD も作れます」のその後のステップとして記述しています。まだその記事を見ていない方は、まずはそちらをご覧ください。以下は、その機能で、テンプレートとして Serverlerss API backend を選択し、プロジェクトリポジトリとして CodeCommit を作成された結果を元に説明しています。CI/CD や CodeCommit をよくご存知の方は読み飛ばしていただいて構いません。 実行テスト 作成されたアプリケーションは、何も変更しなくてもすでに実行できる状態にあります。 例えば、ターミナルなどから以下のコマンドを実行してみてください(なお、下記のように日本語を含むデータで実行する場合は、ターミナルの文字コード設定が UTF-8 であることを確認ください)。 curl -d ‘{“id”:”001″,”name”:”テスト”}’ -H “Content-Type:application/json” -X POST https://<<API EndPoint>> DynamoDBのコンソールをみると、新しいデータが登録されることがわかります。もちろん、好みの REST API テストツール(ブラウザプラグインなど)を使っても構いません。 構成の確認 生成されたアプリケーションで、API 定義、Lambda 関数がどのように定義されているかを見るのは、サーバーレスを始めたばかりの開発者には参考になるかと思います。例えば、API Gateway の構成を見てみると、以下のように設定されていることがわかります。 名称で想像できる通り、3つの関数は、全件検索、データの書き込み、特定 ID のデータの取得のための処理であり、それらが対応する API に紐づけられています。この 3つの処理はよく使われる典型的なものですので、そのコードは、多くの処理で参考になるでしょう。 コードの編集 テンプレートベースのサーバーレスアプリ作成機能で設定された Lambda 関数がどういうものか、コンソールから確認してみましょう。作成したサーバーレスアプリケーションへ Lambda コンソールからアクセスし、その中のリソースのセクションを見ると Lambda Function タイプのものが作成されていることがわかります。 ここにあるリンクをクリックすれば、それぞれの Lambda 関数の画面に飛びますが、そのコードは表示されず、「インラインコード編集を有効にできません」と表示される場合があります。生成されたコードはどこにあるのでしょう? もう一度、Lambda […]

Read More

使用されていないAmazon EBSボリュームを削除してAWSのコストをコントロールする

業界や業種を問わず、お客様にとってコスト管理は最優先事項の1つです。 EBSボリュームのライフサイクルの可視性が十分でないと、未使用のリソースに対してコストが発生する可能性があります。 AWSはコスト管理のサービスを提供しており、コスト情報へのアクセス、コストの理解、コストの制御、およびコストの最適化を行えるようにしています。 未使用、および管理が行き届いていないAmazon EBSボリュームは、AWS のコストに影響します。 EBSボリュームのライフサイクルは、Amazon EC2 コンピューティングインスタンスから独立して管理可能です。そのため、EBS ボリュームに関連付けられている EC2インスタンスが終了しても、EC2起動時に「終了時に削除」 オプションを選択しない限り、EBS ボリュームは削除されません。 また、開発とテストのサイクルの中でEC2インスタンスの起動停止を繰り返す際、自動的にEBSボリュームを削除する処理がないと、 EBS ボリュームが残る可能性があります。 EC2にアタッチされておらず孤立したEBS ボリュームは、アタッチされていない間も料金が発生します。 この記事では、OpsCenter を活用した自動化プロセスについて説明します。OpsCenter は、AWS Systems Manager の一機能として最近発表されたもので、OpsCenterを使えば、EC2 インスタンスにアタッチされておらず、未使用なEBS ボリュームを識別および管理できるようになります。

Read More

新しいサーバーレスアプリ作成機能で CI/CD も作れます

AWS Lambda のマネジメントコンソールに新しい「サーバーレスアプリケーションの作成」機能が追加されていることにお気付きですか? サーバーレス環境である Lambda ではすぐに処理実行環境が利用可能になり、Webのコンソールからロジックを実装するだけで容易にちょっとした処理を開発できます。一方で、この次のステップとして、 Lambda 関数だけでなく、アプリケーションとしての開発や管理ができていない 環境の再現(開発環境からステージングや本番環境へ)、デプロイの継続実行(CI/CD)の環境が整備できずに、Webコンソール上でいまだにコード変更している という話を聞くことがあります。実際には、デプロイ/環境設定のコード化(Infrastructure as Code: IaC)には AWS CloudFormation や Serverless Application Model(SAM)などがあり、CI/CD には CODEシリーズなどがあるのですが、サーバーレス開発を始めたばかりだと、そこへの次の一歩に二の足を踏まれているケースを見かけることがあります。 そんな方に向けた機能が、新しい「サーバーレスアプリケーションの作成」機能です。これを使うと、特定ユースケースのアプリケーションをテンプレートベースでひとまとめに作成し、CI/CD パイプラインまで一気に構築してくれます。 簡単に、この機能の利用ステップを紹介します。

Read More

WinTicket 、 AWS メディアサービスで競輪ファンに高画質レース映像を低遅延ライブで提供

WinTicket は、インターネットテレビ局 AbemaTV の番組「競輪チャンネル」と連動し、24時間どこでも投票チケットを購入できるほか、レース情報・オッズ・ AI 予想機能、そして開催中の熱戦レースのライブ映像を提供しています。 時速 60km ~ 70km で 9 名の選手がレースする中、 WinTicket のユーザーが視聴環境を問わず、レースの状況を高画質・低遅延で視聴できるようにすることは重要です。そのため、 WinTicket は動画配信ワークフローをクラウドに移行し、AWSメディアサービスを活用することで高画質・低遅延のライブ配信を確立させました。 WinTicket のライブ配信は、全国40以上の競輪場から集約した映像で構成されています。 AbemaTV の番組スタジオで映像を集めてクラウドへ伝送し、 AWS Elemental MediaLive で ABR エンコード、 AWS Elemental MediaPackage で HLS にパッケージ化し、 Amazon CloudFront 経由で視聴者へ低遅延なライブ配信しています。 「 WinTicket はサービスの特性上、レース状況や結果がすぐにわかるようにしなければ、ユーザー体験に影響を及ぼしてしまいます。 AWS Media Services は、他のサービスよりも 1.5 倍ほど低いレイテンシでコンテンツを配信できるため、戦略的な強みが得られました。」と、株式会社サイバーエージェントの CATS ソフトウェア エンジニア 江頭 宏亮 氏は語っています。「今回、 AWS Media Services を採用したことで、配信ワークフローの開発工程数を抑えた、冗長性のある可用性の高いライブ配信システムの構築ができました。配信管理ツールとして採用したサーバレスアーキテクチャを含め、利用している時間帯だけ課金されるため、運用コストを抑えられます。また、スケジュール管理上で蓋絵 […]

Read More

Lambda@Edge を使ったゲームプレイヤーへのカスタムコンテンツの配信

モバイルゲームのクライアントアプリを起動した時に、いつも最新のコンテンツを入手できるようにしたいですよね?そうすれば、ゲームへ変更を加えて、新しい機能を追加した際、変更内容をすぐにプレイヤーに提供できるようになります。

Read More