バックエンド HTTP エンドポイント、AWS Lambda 関数、または AWS のその他サービスを公開するための RESTful アプリケーションプログラミングインターフェイス (API) の作成、デプロイ、および管理。 AWS Lambda 関数、または AWS のその他サービスを公開するための WebSocket API の作成、デプロイ、および管理。 フロントエンド HTTP および WebSocket エンドポイントによって公開された API メソッドの呼び出し。 API Gateway REST API バックエンド HTTP エンドポイント、Lambda 関数、または AWS のその他サービスを使用して統合されているリソースおよびメソッドのコレクション。このコレクションは、1 つ以上のステージでデプロイできます。通常、API リソースはアプリケーションロジックに従ってリソー
マイクロサービスアーキテクチャでよく利用される、APIGatewayパターンとBFFについて調べたのでメモ なぜAPIGateway? マイクロサービスアーキテクチャでシステムを構築する場合、複数のサービスを組み合わせる形でシステムが構築される。 たとえば、ECサイトの商品詳細を表示するために、商品情報サービス、レコメンデーションサービス、レビューサービスを利用する必要がある、ということ。この場合アプリケーションの実装によっては並行リクエストを行うのが難しかったり、モバイルアプリケーションの場合は帯域の問題も発生する。（その他にもいろいろあるが割愛） そこで、アプリケーションとサービスの間にAPIGatewayというレイヤーを追加することで問題を解決する。 APIGatewayの実装 単純な場合はこの図のようになって、全てのアプリケーションからのリクエストを１つのAPIGatewayで受け
はじめに こんにちは。EC基盤本部SRE部プラットフォームSREの三神です。 2021年3月18日、ZOZOTOWNは大規模なリニューアルをしました。その中でも、コスメ専門モールのZOZOCOSMEと、ラグジュアリー&デザイナーズゾーンのZOZOVILLAを同時にオープンし、多くの反響をいただきました。 今回のリニューアルではBackends For Frontends（以下、BFF）にあたるZOZO Aggregation APIを構築しています。本記事ではZOZOTOWNが抱えていた課題とBFFアーキテクチャを採用した理由、またZOZO Aggregation API構築時に発生した課題と解決法についてご紹介します。 ZOZO Aggregation APIのサービスメッシュについてはこちらの記事でご紹介していますので合わせてご覧ください。 techblog.zozo.com BFFと
こんにちは。Synergy! 開発チームの松本です。 以前の記事でも少し触れたのですが、当社シナジーマーケティングのプロダクトである Synergy! は、2015 年以前に作られたモノリスと、それ以降に作られたマイクロサービスのハイブリッド型として稼働しています。 この数年、マイクロサービスを実践してきてつくづく感じているのは、全てのチームがマイクロサービスアーキテクチャスタイルの本質を理解した上で開発や運用を行うということの難しさです。「分散されたモノリス」なんていう話も聞きますが、これもやはり、本質を理解しないままマイクロサービスを実践した例です。 2014 年に書かれた martinfowler.com の記事 "Microservices" は、マイクロサービスアーキテクチャを 9 つの特性に分解してその本質を述べた素晴らしいドキュメントです。これをチームの教育に使うことで前述の
はじめに 本記事はMartin Fowler氏のBlog記事を日本語訳したものです。 なお、訳は2014/11/09時点のもので、オリジナル記事中のコラムは訳せていません。コラムの訳に関しては、暇や反応を見ながらぼちぼちやろうと思います。 訳に対する指摘・ご意見などありましたらtwitter(@kimito_k)でお願いします。 補足 Martin Fowler氏に連絡をとったところ、主著者はJames Lewisであるとのことでしたのでタイトルを変更しました。(2014/11/13) Microservices "マイクロサービスアーキテクチャ"という専門用語は、ソフトウェアアプリケーションを独立して配置可能なサービスの組み合わせ(suite)として設計する特定の方法を指すものとして、ここ数年で急速に認知されています。このアーキテクチャスタイルに対する正確な定義はありませんが、ビジネス遂
この記事は ドメイン駆動設計 #1 Advent Calendar 2018 の 21日目 です。 前日は @mafuyuk さんの「DDDをチームに導入する際に考慮した4つのこと」でした。 明日は @dnskimo@github さんです。 この記事の内容 実務でドメイン駆動設計（以下、DDD）とマイクロサービスアーキテクチャを実践していますが、 DDDとマイクロサービスの粒度について、チームメンバーでの解釈が異なっていることもありました。 この記事では、DDDの構成要素とマイクロサービスをどう合わせるのがいいのか？ を考察していきたいと思います。 いきなり結論 先に結論を言ってしまうと、「DDDのサブドメインをマイクロサービスの単位とする」 になると考えます。 境界づけられたコンテキスト : サブドメイン（のドメインモデル） : マイクロサービス が、1 : 1 : 1 になるのが理想
2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く