SRE伝道師としてMicroservices SRE チームが取り組んでいる事例 | メルカリエンジニアリング
※この記事は、"Blog Series of Introduction of Developer Productivity Engineering at Mercari" の一環で書かれています。 著者: Microservices SREチーム @k-oguma（ktykogm） 本記事の内容は、前日の記事である "Embedded SRE at Mercari "の具体的な事例等の紹介となります。私自身が実際にEmbedded SREsとしてプロダクトチームに参加し、その中で発見したプロダクトチームの課題とそれに対して行った取り組みをいくつか紹介したいと思います。最後に具体的な活動を通して見えてきたEmbedded SREsのメリットなどについてまとめます。 本記事内の用語 SRE Site Reliability Engineering の略 信頼性における方法論、概念、ベストプラク
【ZOZOTOWNマイクロサービス化】API Gatewayの可用性を高めるノウハウを惜しみなく大公開 - ZOZO TECH BLOG
はじめに こんにちは。ECプラットフォーム部のAPI基盤チームに所属している籏野 @gold_kou と申します。普段は、GoでAPI GatewayやID基盤（認証マイクロサービス）の開発をしています。 先日、【ZOZOTOWNマイクロサービス化】API Gatewayを自社開発したノウハウ大公開！ を公開したところ、多くの方からご好評いただきました。ありがとうございます。まだ読まれていない方はぜひご覧ください。 techblog.zozo.com 今回はその記事の続きです。API Gatewayは単にリバースプロキシの役割を担うだけでなく、ZOZOTOWN全体の可用性を高める仕組みを用意しています。本記事では、それらの中でカナリアリリース機能・リトライ機能・タイムアウト機能に関して実装レベルの紹介をします。 マイクロサービスに興味ある方や、API Gatewayを自社開発する方の参考に
Microservices における認証と認可の設計パターン
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
モノリス分割はこうやる！「How to break a Monolith into Microservices」を読んだ - kakakakakku blog
研修中に「マイクロサービス」の解説をしていると，たまに「モノリス分割」に関する質問が出てディスカッションをすることがある．当然ながら万能な分割アプローチはないけど，例えば DDD (Domain-driven design) などのアプローチを選択するなど，選択肢はいろいろある．そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ． 具体的には以下の「計8種類」のアプローチが紹介されている．原著を翻訳するのではなく，あくまで個人的なメモとしてまとめる．なお，日本語も個人的に載せているため，参考程度にしてもらればと！ Warm Up with a Simple and Fairly Decoupled Capability（シンプルかつ分離された機能で準
Microservices分割大全 - kawasima
Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ
理解して拡げる分散システムの基礎知識
20200725の #JTF2020 セッションスライド。 （資料内で説明した資料へのリンク） ・昨年のJTF発表資料 https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kubernetes ・「2020年のNewSQL」 https://qiita.com/tzkoba/items/5316c6eac66510233115 ・「NewSQLのコンポーネント詳解」 https://qiita.com/tzkoba/items/3e875e5a6ccd99af332f ・Saga https://www.infoq.com/jp/news/2018/03/data-consistency-microservices/ ・「マイクロサービスとは分散システムである」 https://
Istioがマイクロサービスからモノリシックなアプリに変化。その背景とは
サービスメッシュを実装するオープンソースソフトウェアIstioが最新バージョンを公開した。このリリースではこれまでのコントロールプレーンの発想を一新して、複数のプロセスが協調する形から、「istiod」というモノリシックなプロセスが制御を行う方式に変更されたことが明らかになった。 バージョンアップの概要はIstioのブログ記事にあるが、より詳細にマイクロサービスからモノリシックへの変更に関しては、Christian Posta氏によるブログ記事が参考になる。 公式サイト：Istio in 2020 - Following the Trade Winds Solo.incのField CTOであるPosta氏はRed Hatのアーキテクトというキャリアの持ち主で、2019年11月のKubeConではマイクロサービスを指向するプログラミング言語であるBallerinaのセッションを行ったことも
マイクロサービスのアプリケーションログ転送量の抑制と改善 | DevelopersIO
はじめに こんにちは。こむろ＠事業開発部です。あ、今回も改善の話です。新機能開発とかそういった話はありませんのであしからず。 所属している事業開発部では、prismatixというECプラットフォームサービスを開発・運用しております。ECですので、商品の管理、検索、購入や会員管理等の多種多様な機能があり、それぞれのサービスでは日々膨大なアプリケーションログを記録しています。 アプリケーションログは正常動作している時は、あまり必要ではないのですが、いざ何らかの問題が発生した際に、原因究明やデータ復旧には欠かせないデータです。従って保険としてできれば全てを保存しておきたいところです。 しかしながら、このログの保存。機能の数やリクエスト規模にもよりますが、膨大が故に非常にお金がかかります。そして正直なところ大抵は利用されないゴミです。 *1 このあたりの話については、Release It! 本番用
Monolith によるモダンアーキテクチャの再考 / Rethink modern architectures with Monolith
Cloud Native Meetup Tokyo #11 「Monolith によるモダンアーキテクチャの再考」のスライド資料です
マイクロサービス環境でのメルカリWebのリリースフロー
メルカリJP Webチームの@urahiroshiです。 Webチームでは、メルカリWebのマイクロサービス化や機能開発を行なっています。メルカリWebのマイクロサービス化の概要については、昨年のTech Conferenceの資料がよくまとまっているので、そちらを参照していただけると良いかと思います。 https://speakerdeck.com/mercari/mtc2018-web-application-as-a-microservice-3a161f5c-07fa-4dca-99e9-bd0e8feeeddf 現在、メルカリWebのトップページはマイクロサービス環境から配信されており、他のページも随時マイクロサービス環境に移行していく予定です。 この記事では、マイクロサービス環境で導入した、メルカリWebの新しいリリースフローについて記載します。 まずメルカリWebのマイクロサ
Microservices と会計システム | メルカリエンジニアリング
この記事は、 Mercari Bold Challenge Month の18日目の記事です。 こんにちは。メルカリで Product Manager として働いている津田と申します。私は社内で「会計システム」と呼ばれる、会社が運営するサービスに付随して発生した債権債務の増減を記録・集計するシステムを開発するチームで働いています。 はじめに メルカリでは、お客さまの行動に応じて日々さまざまなお金の流れが発生しています。たとえばメルカリで商品が出品され購入された（取引が行われた）場合を考えてみます。 この取引は、会社から見るとそれぞれの相手先に対する債権債務関係の変化と捉えることができます。メルカリにとっては、購入したお客さまに対する債権（= 商品代金）と出品したお客さまに対する債務（= 売上金）が発生します。このとき、商品代金の一定割合（通常は 10%）が販売手数料としてメルカリの売上とな
メルペイのマイクロサービスの構築と運用 / CloudNative Days Tokyo2019
メルペイのマイクロサービスの構築と運用 2019.07.22 に CloudNative Days Tokyo2019 で発表した内容です。 なぜメルペイがマイクロサービスアーキテクチャを選択したか、メルペイのマイクロサービスの構築と運用をどのように行ったか、などを話しました。
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
Merpay Microservices on Microservices Platform | Mercari Engineering
この記事は MERPAY TECH OPENNESS MONTH の14日目の記事です。 メルペイSREの @tjun です。Engineering Managerをやっています。 先月行われた Mercari Meetup for Microservices Platform #2で、 Merpay Microservices on Microservices Platformというタイトルで、メルペイのマイクロサービスがどのようにMicroservices Platformを利用してサービスを開発・運用しているかを発表しました。 本記事は、そこでの発表内容をblogとして記事にしたものになります。 その他の発表については @masartz の記事 Mercari Meetup for Microservices Platform #2 を開催しました – Mercari Enginee
Microservices for Everyone - 2つの "why-microservices" を読んで｜qsona
どちらも大変素晴らしい記事で、大変よくまとまっていながら主張が入っていて読みごたえのある文だった。それに比べたら、以下の文はまとまりもない駄文だが、それでもどうしてもこの話題には物申したくなる自分がいる。知見と呼べるほどでもないけれど、3年間マイクロサービスのことを考え続けてきた者の率直な感想として、読んでいってもらえたら嬉しい。 tl;drこの記事を通して、僕が結局何が言いたいのかというと、マイクロサービスはもっと開かれたものであってほしいということだ。複数のビジネスをやるならマイクロサービスの考え方を導入する権利があるし、すでにマイクロサービスをやっているなら、マイクロサービスのことを考えるのは基盤チームだけじゃなくてみんなであるべきだ。 マイクロサービスは「やる」か「やらない」かではない前者のdeeeetさんの記事は、全くマイクロサービスを知らない人がぜひ読むべき、本当に良い記事だと
なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
Microservices時代の監視設計 - An Epicurean
前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでにMicroservicesでバリバリやっている人は読む必要ないと思います。 前回の最後にMicroservices時代になると、開発者がこれまで以上に監視に取り組んでいく必要があると言う話を書きました。多少重複するところもありますが、その辺りから話を始めます。 モノリシック世界観での監視 アプリケーション監視の浸透 Microservices時代の監視設計 開発者自身が監視する どう監視するか メトリクス設計 The Four Golden Signals USEメソッド REDメソッド USEとREDの補完関係 The Four Golden Signalsの素晴らしさ 例: ある認証コンポーネントの監視設計 まとめ モノリシック世界観での監視 Webサービスの構成が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://engineering.mercari.com/entry/2019/12/01/microservices-migration-progress
なぜ Go はマイクロサービスのための言語なのか - Why Go is a language for microservices
How we monitor microservices at Mercari microservices platform team
