MicroservicesとBFFで成したかった世界[BFF Meetup 〜Ruby/Go/Kotlin〜 ※言語別クライアント連携編 \- connpass](https://azit.connpass.com/event/125152/) 懇親会ありきで話を散らかしに行く＆内容の正確性よりも気持ちを伝えたかった スタイルの登壇なのでスライドの防御力がとても弱いです。 それ合ってる…？みたいなところが多いかもですが優しく見守っていただけますと幸いです。
Microservices と会計システム | メルカリエンジニアリング
この記事は、 Mercari Bold Challenge Month の18日目の記事です。 こんにちは。メルカリで Product Manager として働いている津田と申します。私は社内で「会計システム」と呼ばれる、会社が運営するサービスに付随して発生した債権債務の増減を記録・集計するシステムを開発するチームで働いています。 はじめに メルカリでは、お客さまの行動に応じて日々さまざまなお金の流れが発生しています。たとえばメルカリで商品が出品され購入された（取引が行われた）場合を考えてみます。 この取引は、会社から見るとそれぞれの相手先に対する債権債務関係の変化と捉えることができます。メルカリにとっては、購入したお客さまに対する債権（= 商品代金）と出品したお客さまに対する債務（= 売上金）が発生します。このとき、商品代金の一定割合（通常は 10%）が販売手数料としてメルカリの売上とな
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
gRPCを用いたマイクロサービスのAPI仕様の記述 - Mercari Engineering Blog
この記事はMERPAY TECH OPENNESS MONTHの10日目の記事です。 こんにちは、メルペイのバックエンドエンジニアの柴田（@yoshiki_shibata）です。 メルペイのバックエンドは、Google Cloud Platform上でGoogle Kubernetes Engineを使用して、マイクロサービスアーキテクチャを採用した多数のマイクロサービスから構成されています。モノリシックなサービス実装では複数層のライブラリ（あるいはコンポーネント）から構成されるのに対して、マイクロサービスアーキテクチャでは複数層のマイクロサービスから構成されます。 どちらのアーキテクチャにおいても、偶発的プログラミング（Programming by Coincidence）1を避ける2ために、注意を払って作成する必要があるのが、境界部分のAPI（Application Programmi
なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
Microservicesでなぜ作るのか - An Epicurean
「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流
半年で250回のリリース!? FiNCアプリのオンボーディングMicroserviceの裏側
FiNCアプリは数十ものMicroservicesに分かれていますが、アプリを初めて利用した時に開始されるオンボーディングも、1つのMicroserviceとして存在しています。 チャットUIの応答式オンボーディングFiNCのオンボーディングは、会社の継続率/LTVの大部分を支えている実はFiNCアプリのオンボーディングは、内容をチューニングしただけでもアプリの継続率を1.5倍~2倍にしたり、会社の大部分の売り上げを支える企画をいくつも実現するなど、数ある中でも最も重要なMicroserviceになっています。 社内での運用ペースも凄まじく、実に半年で250回もの変更がリリースされています。リリースはデプロイを必要とせず、専用の管理画面から反映する作業は2~3分程度で行えます。 この記事ではそんなオンボーディングのMicroserviceをテーマに、以下のポイントについてまとめたいと思いま
クックパッド基幹システムのmicroservices化戦略 〜お台場プロジェクト1年半の軌跡〜 - クックパッド開発者ブログ
インフラストラクチャー部の青木峰郎です。 最近はDWH運用の傍ら、所属とまったく関係のないサービス開発のためのデザインスプリントをしつつ、 Java 10でgRPCサーバーを書きつつ、 リアクティブプログラミングを使った非同期オーケストレーション層を勢いだけで導入したりしています。 ですが今日はそれとはあまり関係なく、クックパッドの中核サービスであるレシピサービスの アーキテクチャ改善プロジェクト、「お台場プロジェクト」の戦略について話します。 これまで、お台場プロジェクトで行った施策について対外的に発表したことはあっても、 全体戦略について話したことはありませんでした。 その一番の理由は、正直に言って、プロジェクトオーナーであるわたしにもプロジェクト全体の姿が見えていなかったからです。 しかし現在プロジェクト開始から1年半が経過してようやく全貌が見えてきたので、すべてをお話ししようと思い
Backends For Frontends (AWS Dev Day) - Speaker Deck
AWS Dev Day で発表した Backends For Frontends の話です。
マイクロサービスバックエンドAPIのためのRESTとgRPC
7. > In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. => HTTP API Microservices @Martin Fowler, @James Lewis https://martinfowler.com/articles/microservices.html 8. RESTful API > RESTful API Web (API) REST REST REST
メルカリが「マイクロサービス」に本気で取り組む理由
メルカリは現在300人程度の開発者を1000人規模にする目標を掲げており、それに合わせてパフォーマンスを発揮させるためにマイクロサービスアーキテクチャを1年前から採用し始めました。同社がこの1年、マイクロサービスアーキテクチャにどう取り組み、実現のためになにをしてきたのか。技術面と組織面の双方に関する興味深い取り組みが、10月4日に都内で行われた同社主催の技術カンファレンス「Mercari Tech Conf 2018」のセッション「Microservices Platform at Mercari」で紹介されました。この記事はその内容をダイジェストでまとめたものです（本記事は前編と後編に分かれています）。 ITジャーナリスト／Publickeyブロガー。大学でUNIXを学び、株式会社アスキーに入社。データベースのテクニカルサポート、月刊アスキーNT編集部 副編集長などを経て1998年退社
Microservice で実現するメルカリオファー機能 | メルカリエンジニアリング
こんにちは、 Backend Engineer の @vkgtaro です。 メルカリでは今まで PHP で開発されたモノリシックな API に対して機能を追加してきたのですが、今後メルカリのシステムを Microservices 化していくその先駆けとして、Offer という新機能を Microservices Platform 上で開発・リリースしました。Offer は今までコメント欄でなされていた値下げ要求を機能としてできるようにしたもので、出品者から承諾が得られれば Offer した金額で購入できるというものです。受け取った人はもちろん断ることもできます。 2018/07/10 現在、「インテリア・住まい・小物」カテゴリーにて使用可能になっています。 今回はこの機能を実装するにあたってやったことをいろいろ振り返ってみようと思います。 ざっくり全体像はこんな感じになってます。 端末と
API GatewayによるMicroservices化
API GatewayによるMicroservices化 mercari.go#1 3 July 2018 Taichi Nakashima About me @deeeet / @tcnksm (GitHub) Blog on deeeet.com Tech lead at Mercari microservices platform team 2 Mercari Meetup for Microservices Platform 7/19 遊びに来てくれ！ https://mercari.connpass.com/event/92168/ 3 tl;dr Mercari Microservices化のために開発したAPI Gatewayについて紹介する． API Gatewayとは何か? API Gatewayの設計思想は? API Gatewayの機能の実装方法は? API Gate
US版Mercariのリニューアルと今後 (サーバサイド)
この記事はMercari Advent Calendar10日目の記事です。昨日は@syu_creamのメルカリのデータ分析基盤の紹介〜BigQuery周辺の話〜でした。 本日はUSサンフランシスコのサーバサイドエンジニア@deme0607が、今年2017年にリニューアルしたUS版Mercariのサーバサイドについてご紹介します。 現在のアーキテクチャ Brand new US Mercari (Android 編)でもご紹介したように、US版Mercariは今年、より一層USマーケットにフィットしたアプリを提供しUSでの成長を加速すべく、大きなリニューアルが実施されました。前述の記事はAndroidアプリのリニューアルに関するものですが、iOSアプリやAPIサーバも同様にリニューアルしています。 以下の図は、リニューアル後のUS版Mercariのサーバサイドアーキテクチャです。 ここでは
マイクロサービスはもう十分 | プロダクト・サービス | POSTD
モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠
microservicesにおけるAPI自動テストにまつわるエトセトラ
Test Engineers Meetup #2 https://test-engineers-meetup.connpass.com/event/50496/
第3回Reactive System Meetup in 西新宿 (2016/09/29 19:00〜)
リアクティブ × DDD × マイクロサービス リアクティブシステムをテーマにした勉強会、今回のサブテーマは、リアクティブ×DDD×マイクロサービスです。 ゲストスピーカーとしてChatWorkのかとじゅん（@j5ik2o）さんにご講演いただきます。 リアクティブ・システムとは リアクティブ・システムは、メッセージ駆動のアーキテクチャによりユーザーの要求に可能な限り迅速にレスポンスするシステムです。高負荷状況や問題が検出された時でも応答時間を一定水準に保ち、部分的な障害が発生した時にもシステム全体を危険にさらすことなく回復させます。（リアクティブ宣言もご参照下さい。） 開催概要 日時 2016年9月29日(木) 19:00 〜 22:30 18:30 開場、21:10 より交流会 会場 bit & innovation 「bit & innovation」はTIS株式会社が運営するコワーキ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FiNCでの5年間に渡る マイクロサービスの育て方 / microservices at FiNC - Speaker Deck
マイクロサービスと設計原則 / Microservices and Design Principles - Speaker Deck
Microservices on Fastly
