$request_id Nginx 1.11.0 以降に限りますが、リクエスト毎に発番されるIDの変数として $request_id が追加されたようです。 http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_id この変数を利用することにより、Nginxコアだけでサービス間のトレースを簡単に行うことが可能になります。 シンプルな例 以下のように、$request_idをログに含めるだけでリクエスト毎のIDを記録できます。 http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "
マイクロサービスのデザインパターン
第1版 2015年9月21日 第2版 2015年12月24日 Bluemixでは，たくさんのサービスやAPIが提供されており，それらを組み合わせることでアプリケーションを開発することができます．単一のプログラム言語を使って，多数のライブラリやクラスファイルを結合して作る大きなアプリケーションにももちろん利点がありますが，新しい機能やUXを継続的に提供したい時や，目的に合わせてプログラミング言語やデータベースを選択したい場合には，それぞれが独立したサービスを組み合わせるやり方が有利です．この考え方の根底にあるのが，James LewisとMartin Fowlerが提唱しているマイクロサービスです．彼らのブログ記事にあるマイクロサービスの定義にあたる部分を訳してみました． マイクロサービス(Microservices)アーキテクチャスタイルは、それぞれが独立のプロセスで実行され，HTTPリソ
マイクロサービスについて考えていたら疲弊したので、少し技術者らしく形式的に見てダメのものを思考から削ぎ落としたいと思った。 グラフ理論などコンピュータサイエンスの基礎を交えて話をするが、基本的には当たり前のことしか言わないと思うのでここに書くことを意識せずとも暗黙的に実践している人も多いだろう。 なお、個人の意見でしかないのであっているか間違っているかはわからないし、筆者にこの記述に反した実装を否定する意図はない。 今回は適当に書き散らかすのでかなりテイストが違うが他のブログと同一人物が書いている。乗っ取り等ではないです。 TL;DR マイクロサービスはDAGとすると考えやすいしデプロイしやすい 閉路があるなら設計を見直した方がいい DAGかどうかはサブシステムレベルでそれぞれ考えると簡単 デプロイに関係するリポジトリでは閉路がないことを意識させる設計にするといい マイクロサービスと疲弊
https://mercari.connpass.com/event/124342/
Kubernetes導入で実現したい世界とその先にあるMicroservices - スタディサプリ Product Team Blog
はじめに CTO兼SREエンジニアリングマネージャーの中野です。ここしばらくの間、CTO/SREエンジニアリングマネージャーとして注力しているKubernetes導入について紹介したいと思います。 今回は、Kubernetes自体がどういうものなのかということより、それをツールとしてどう使い、それでどういう世界を実現したいのかみたいなところを中心に紹介できたらと思います。 まず現在の状況ですが、Quipperでは、大きく分けてスタディサプリの小中高校生向けと日本以外向けの2つのサービスを展開しています。サービスとしての構成はほぼ同じですが、基盤としては別々のAWSアカウントで運営されています。このうち日本国外向け環境では、Kubernetes化がほぼ完了というステータスになっています。目下、スタディサプリも移行中です。 Kubernetes化以前は、Deis(Herokuクローン的なもの)
JAWS DAYS 2018
大きく変化した「人とシステム」の関係 企業におけるDX（デジタルトランスフォーメーション）の取り組みが加速する中で、「マイクロサービスアーキテクチャ」（以下、マイクロサービス）の注目度が増している。マイクロサービスは、複数の小さなサービスを組み合わせて一つのシステムを構成するという考え方だ。 マイクロサービスのような「疎結合アーキテクチャ」自体は以前からあるが、「クラウド」「モバイル」といった技術や考え方が普及したことで最近特に注目されている。こう語るのは、Scalarの深津 航氏（CEO、COO＜最高執行責任者＞）だ。 「技術の進歩によって人とシステムの関係が大きく変化した2000年ごろは、社内の情報は社内のシステムに格納され、他社と情報をやりとりするのは主に“人”だった。しかし、2010年ごろになると企業と企業のやりとりも、メールや電話だけでなく、スマートフォンのアプリケーションやWe
at Rails developer meetup 2018 Day 2 Sample code: https://github.com/cnosuke/bank_sample
JJUG CCC 2019 Springでの登壇資料です
最近では「マイクロサービス」と呼ばれる、機能毎に細かくサービスを分割して開発や運用を行うアーキテクチャの採用例が増えている。本記事ではこのマイクロサービスアーキテクチャや、それに使われる技術について紹介する。 マイクロサービスとは 近年、ITシステムの開発・運用において「Microservice（マイクロサービス）」というアーキテクチャを採用する例が増えている。マイクロサービスアーキテクチャは、簡単に言えばサービスを構成する各要素を「マイクロサービス」と呼ばれる独立した小さなコンポーネントとして実装するという手法で、2011年ごろから提唱されているものだ。 マイクロサービスについては、2014年に公開された「Microservices」という文書が有名だ（有志による日本語訳）。また、さくらのナレッジでも2015年に紹介されている。マイクロサービスの詳しい思想についてはこれら記事を参照してほ
Brendan Burns, David Oppenheimerらの論文「Design patterns for container-based distributed systems」を読んで、コンテナを活用したシステム設計や開発に、とても有用と感じたので、図を中心にした要約にしてみた。 要約内容に誤りや理解不足な部分もあると思うので、原文も参照していただきたい。また、自身の理解のために、論文中に無い図を加えた点、独自の注釈も加えている。 背景 コンテナ化されたソフトウェアコンポーネントから構築されたマイクロサービスアーキテクチャの人気が高まり、分散システム開発においても同様の革命が起っている。 コンテナの境界の壁は、分散システムの基本的なオブジェクトの境界に適している。そこで、コンテナを活用して、コードの低レベルの詳細を抽象化し、アプリケーションやアルゴリズムに共通する高レベルのパター
GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.
Architecture styles define how different components of an application programming interface (API) interact with one another. As a result, they ensure efficiency, reliability, and ease of integration with other systems by providing a standard approach to designing and building APIs. Here are the most used styles: SOAP: Mature, comprehensive, XML-based Best for enterprise applications RESTful: Popul
Kubernetes の導入時に考えるべきこと
Azure にシステム導入・移行するお客様に日頃ご支援をさせていただいているのですが、多くのお客様やエンジニアの皆様から、たびたび似たようなご質問を頂くので、その内容をここに紹介したいと思います。(実際、今日もとあるお客様で下記のご相談を頂いたので) ご質問： お客様からたびたび頂くご質問の例 このシステムを Kubernetes (AKS) 上で構築するのは正しいですか？ とあるコンサルから Kubernetes を導入しないと会社の未来はないと言われたのですが、本当ですか？ 今、Azure Web App for Container か AKS (Kubernetes) の何れかの選択で悩んでいるのですが、どちらが良いですか？ 今、このような Kubernetes(AKS) のシステム構成を考えているのですが、正しいですか？ 質問の背景： これらのご質問は、メッセージは異なるのですが基
技術部の taiki45 です。 現在のクックパッドでは、cookpad.com 内のデータを利用するようなプロダクトでも、cookpad.com を提供しているアプリケーション(本体アプリケーション)とは別に新規のアプリケーションとして設計・実装しています。また、すでに本体アプリケーションの一部として実装されているプロダクトについても、トレードオフを考慮しながら場合によっては、本体アプリケーションから独立した別のアプリケーションとして設計・実装することが増えてきています。これらの本体アプリケーションや、新規にあるいは本体アプリケーションから独立させて設計・実装したアプリケーションのことを「サービス」と呼んでいます。また、この本体アプリケーションから独立させることを「サービス分割」と呼んでいます。 制御できないほどの巨大な複雑なまとまりを制御するために、その巨大なまとまりと単純なまとまりに
お久しぶりです、かとじゅん(@j5ik2o)です。テックブログを書くのは何年ぶりか…。 サービスが停止したり応答性が低下すると、お叱りや逆に励ましをいただきますが、エンジニアとして設計レベルからそういった問題に対処するにはどうするか、日々精進しているところですmm。この記事はそういう論点で注目されている「リアクティブ原則」についてまとめてみたいと思います。 それなりのボリュームになってしまったので、時間があるときに読んでいただければと思います。 さて、Linux Foundation内の新たなトップレベルプロジェクトであるReactive Foundationが主催する、Reactive Summit 2020が11月10日にオンラインで開催されたので参加しました。 www.reactivesummit.org 参加されていたスピーカーはLightbendをはじめ、Netflix, Fac
この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神（注・人名であり実名です）」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、
1) Mercari has transitioned some services to microservices architecture running on Kubernetes in the US region to improve development velocity. 2) Key challenges in operating microservices include deployment automation using Spinnaker, and observability of distributed systems through request tracing, logging, and metrics. 3) The architecture is still evolving with discussions on service mesh and c
Kubernetesを統合したDockerがついにリリース。Docker for Mac with Kubernetesのベータ版が公開
Kubernetesを統合したDockerがついにリリース。Docker for Mac with Kubernetesのベータ版が公開 Docker社は、Kubernetesを統合したmacOS向けのDockerをベータ版として公開したことを明らかにしました。Community Editionで公開されているため、誰でも無料で利用できます。 Announcing #Docker for Mac with #Kubernetes - available with the latest Edge release for #Mac. https://t.co/o1vR5FNjgj pic.twitter.com/JLtc23ssQB — Docker (@Docker) 2018年1月10日 Docker社は昨年、2017年10月にDockerとコンテナオーケストレーションツールのKubern
Webサービスの初期開発とマイクロサービス・BFF Microservices Meetup vol.5 (API Gateway & BFF) 2017/3/30 @FiNC
Chris Richardson 氏の Microservices Patterns を読んだ。 Microservices Patterns: With examples in Java 作者: Chris Richardson出版社/メーカー: Manning Publications発売日: 2018/11/19メディア: ペーパーバックこの商品を含むブログを見る マイクロサービスという言葉が出て来て数年経ちます。 私もマイクロサービス的な複数のサービス間でデータのやり取りを頻繁にするようなシステムを構築したことがあります。 その際にデータの整合性は最重要ではなかったのでトランザクション的なものは使いませんでしが、 お金を扱うようなシステムをマイクロサービスにした場合ちゃんとしたトランザクションはどうするのかは気になっていました。 本書にはその疑問に対する現実的な回答が載っています。
人工衛星の運用を支えるクラウドネイティブ民主化への取り組み / Efforts toward cloud-native democratization for satellite operations
こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、Fargateを本番投入し1ヶ月強が過ぎたので、運用する中で気付いた点について書こうと思います。 以前書いた、Fargateに関する調査のまとめ記事はこちら。 tech.connehito.com 内容はざっくり下記3項目です。 いきなりFargateはハードルが高め 良かった点 コンテナのリソースキャパシティを簡単に変更出来る オートスケーリングもシンプルに組める 安定運用 つらい点 タスクの起動速度がEC2バックエンドと比べるとやはり遅い 料金面 いきなりFargateはハードルが高め Fargate導入を通して一番感じたのは、新規にコンテナ化するアプリケーションをECSで動かす場合、EC2バックエンドで試験をパス出来る状態まで持っていった後に、最後にFargateで動かすパターンがよさそうということです。 今回のF
フロントエンドエンジニアは Micro Frontends の夢を見るか - Mercari Engineering Blog
Mercari Advent Calendar 2018 の6日目はフロントエンドチームの @vwxyutarooo がお送りします。 このタイトルが言いたくて Micro Frontends の記事を書きました。皆さんは Micro Frontends という言葉を聞いたことがあるでしょうか? 私は数ヶ月前まで全く知りませんでした。メルカリのフロントエンドチームにて Micro Frontends に関して考える機会があったので、Micro Frontends とはなんなのか。何をどのように解決しようとしているのかという内容を紹介します。 Micro Frontends とは Micro Frontends という考え方は ThoughtWorks Technology Radar にて2016年に初めて登場したと言われています。日本語で言うときは複数形は無視して "マイクロフロントエン
Rancher meetup #15で発表したKubernetesの永続化ストレージの必要性と基礎について説明した資料となります。
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
![CQRS実践入門 [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/fe5018ad772252621db406116ce62131478fb6b1/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20191202%2F20191202061944.png)
Jason Warner(Now: MD @redpoint, Prior: CTO @github, @heroku, @Canonical)がマイクロサービスについての考えをツイートしたところ「GithubのCTOが『マイクロサービスは失敗だった』と言っている」みたいに一部分だけ切り取ってバズった。そういうのは本当に良くないのでちゃんと全文を読もうよと言うことでまとめた。
freee会計からマイクロサービスを切り出すのに4年かかりました / 4 Years for Carving Out A Micro Service from freee Accounting.
freee会計からマイクロサービスを切り出すのに4年かかりました / 4 Years for Carving Out A Micro Service from freee Accounting.
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
Google、IBMらがオープンソースの「Istio」公開。マイクロサービスのためのネットワーク機能「サービスメッシュ」を提供。Kubernetes対応
Google、IBMらがオープンソースの「Istio」公開。マイクロサービスのためのネットワーク機能「サービスメッシュ」を提供。Kubernetes対応 クラウド時代のアプリケーションは、サービスを提供するコンポーネントのような小さなソフトウェアが多数連係する、いわゆる「マイクロサービス」と呼ばれるアーキテクチャを備えたものになると考えられています。 このマイクロサービスアーキテクチャを備えたアプリケーションの内部では、各サービス間をつなぐためのネットワークがまるで網の目のように張り巡らせられ、そこでさまざまなトラフィックが発生していきます。 そしてこのネットワークを安定的かつ効率的でセキュアに運用することはマイクロサービスの運用に欠かせない基盤であり、そのためにはトラフィックのルーティングルールの設定、トラフィックが偏らないようにロードバランスの実現、セキュリティのための暗号化通信や認証
監視 入門 ~ マイクロサービス時代の監視設計
Profile id: Songmu (ソンムー) Masayuki Matsuki / 松木雅幸 おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/ https://metacpan.org/author/SONGMU はてな東京オフィス チーフエンジニア Mackerel プロダクトマネージャー 60+ CPAN Modules 3 Times ISUCON Winner Using Perl YAPC::Tokyo 2019 ベストスピーカー
▼イベント▼ Spring Fest 2021 https://springfest2021.springframework.jp/ ▼配信アーカイブ▼ https://www.youtube.com/watch?v=9-yDaFlGTxE
Why gRPC?gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend
初めまして、qsona (tw) と申します。Ruby on Rails Advent Calendar 2016 6日目の記事になります。 Rails歴は10ヶ月で、もちろんAdvent Calendarへの参戦も初です。 全体的に生意気な内容と思いますが、 じゃんじゃんマサカリ投げてください お手柔らかにお願いします。 はじめに 環境 JSONを返すAPIで、データベースはRDBを想定してます。 あんまり関係ないですが一応、Rails5 (api mode) + MySQLを想定しています。 マイクロサービスとしてのバックエンドに使う技術スタックの必要な要件 マイクロサービスの良いところは、サービスごとに合った別々の技術が使えるということです。 とはいえ、一般的な組織であれば、学習コストの面などから、ファーストチョイスとなる言語があり、普通の要件に対してはその言語を使う、ということにな
EC2 Auto-ScalingでECS組んでますか？エラーレート高いですか？救ってあげてもいいですか？ | CyberAgent Developers Blog
EC2 Auto-ScalingでECS組んでますか？エラーレート高いですか？救ってあげてもいいですか？ サイバーエージェント技術本部インフラエンジニアの@prog893です。今回も「AWA」という音楽ストリーミングサービスのインフラの改善について紹介したいと思います。前回の記事では、データベースの復旧時間が12時間から55分まで短縮できた話を紹介しましたが、今回は楽曲ダウンロード及びストリーミングレイヤーでのエラー率を大幅に改善したことについて述べたいと思います。 楽曲ダウンロード及びストリーミングの構成 まず、楽曲ダウンロード及びストリーミングの構成概要について紹介します。 音楽ダウンロード及びストリーミングの構成概要 楽曲配信サーバ(以降Track Proxy)はコンテナとして実行しAWS Elastic Container Service（ECS）で運用しており、ECSのバックエン
アーキテクチャの議論でよく出てくるのが、コンウェイの法則と、逆コンウェイ戦略です。これについては、うっかりIT用語をバズらせてしまう達人のマーチン・ファウラーのブログにも詳しい説明があります。角さん、いつも翻訳ありがとうございます。 「逆コンウェイの法則」が持ち出された議論が苦手なんどけど、なんでなのかな。コンウェイの法則はよく理解できるんだがー。 — Kazunori Otani (@katzchang) February 28, 2023 この@katzchangさんのツイートもそうですが、逆コンウェイ戦略に関しては僕も少しモヤモヤするところが個人的にあり、そのあたりを周りの人（@katzchangさんや@tokoroten、@__garsue__氏）と議論したらいろいろ自分が思っていなかった知見も得られたりしたので、まとめてみます。 コミュニケーションがかえって増える問題コンウェイの
マイクロサービスアーキテクチャ（以下、MSA）という言葉を聞くようになりました。きっかけはファウラーのブログ「Microservices」（2014年3月）ですが、昨年10月のJavaOne SFでも多くの講演でMicroservicesという言葉を聞かれ、多くのエンジニアがすぐに共感していたことが分かりました。今後、日本でも広く知られる言葉になることでしょう。 一方でMSAは誤解を招きやすいバズワードとも言える気がします。というわけで、僕なりのMSAについての考えをまとめてみました。 MSAは「優れたウェブサービスを観察したところ同じようなアーキテクチャだったので、それをマイクロサービスアーキテクチャと名付けた」というものです。逆に言えば「大きなウェブサービスを作ろうと思ったときの定石」といえます。「各要素を疎結合に構成し、連携する」「それぞれの要素に適した技術を使う」といったアイデアは
PythonでもPythonじゃなくても使える汎用的なMicroservice実行環境 / nikkei microservice
PythonでもPythonじゃなくても使える汎用的なMicroservice実行環境 / nikkei microservice
皆さんは、The Tweleve-Factor Appをご存知だろうか？ これはHerokuの中の人が書いた、Webアプリケーションを使いやすい形でスケーラブルにするための方法論である。簡単にいえばコンテナで動かしたいアプリケーションが守っておくとよいレシピ集であると言える。 http://12factor.net/ (日本語訳) 今回これを取り上げた背景としては、実はDockerコンテナをメインにした本番でのインフラ運用を考えた時に、アプリケーションがこの12の要素を満たしていることが重要だと最近ひしひし感じているから。 実際、自分が働いているところが運営しているサービス Wantedlyは、もともとずっとHerokuで運営していて、最近AWSに移行し、現在Dockerコンテナの上で動いている。この移行を約1ヶ月半で実現できた大きな要因として、Herokuの上に乗っていたことで知らず知ら
コンウェイの法則とかで、マイクロサービス=組織 という話になることが多いなと感じる。 正解の場合もあるし、不正解の場合もあると思っていて、個人的には小さいチームでもマイクロサービスをやるメリットは技術的にも組織的にもあると思う。 そのメリットを無視してすぐ組織の話に持っていきたくないので、基本分離したくないマンとしての主張を書いておく 技術観点でのメリット いまさら語るまでもないけど、 ドメイン境界の分離 デプロイ独立性 リソースの最適配分 障害の局所化(サーキットブレーカー等) このうち、ドメイン境界の分離だけはモジュラモノリスで対応可能だが、あとの3つにはマイクロサービスが必須。(もっとあるかも) この3つが必要なのにモノリス or モジュラモノリス で進める判断をするということはシステムの表現力を落とすことに直結する。 もちろん、複雑度は増すし難易度も増す。熟練のサーバーサイドエンジ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NginxでWebサーバ間をトレースするrequest_id - Qiita
マイクロサービスを形式的に見てみる - Juju-62q's blog
iD決済を支える技術 / #merpay_techtalk
コンテナを守る技術2018/container-security-20180310
マイクロサービス化による「DB分割」で開発、運用が難しくなるこれだけの理由
https://ubiteku.oinker.me/2017/02/21/docker-and-kubernetes-intro/
fintechtorailstogrpcto?slide=25
初めてのgRPC / Starting gRPC
マイクロサービスアーキテクチャとそれを支える技術 | さくらのナレッジ
コンテナ・デザイン・パターンの論文要約 - Qiita
サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ
リアクティブは難しいが役に立つ - Chatwork Creator's Note
マイクロサービス時代のセッション管理 - Retty Tech Blog
Microservices at Mercari
Webサービスの初期開発とマイクロサービス・BFF
Microservices Patterns を読んで(1) - kencharosの日記
金融系サービスで ECS/Fargateを設計するということ
AWS Fargateを本番運用した所感 - コネヒト開発者ブログ
Kubernetesの永続化ストレージ基礎 - Speaker Deck
CQRS実践入門 [ドメイン駆動設計] - little hands' lab
Jason Warnerとマイクロサービス - 西尾泰和のScrapbox
DDDで設計するならCQRSの利用を検討すべき - Qiita
2021.12.3 - 決済システムで学ぶレジリエントなサービスのいろは
gRPC
マイクロサービス時代に捧ぐ、Railsでの中規模APIサーバ開発のための技術構成 - Qiita
本当は怖い、逆コンウェイ戦略 | フューチャー技術ブログ
マイクロサービスアーキテクチャとは何か - arclamp
12 Factor App - モダンなサービス運営に必要な12のインフラ的要素 - Qiita
マイクロサービスでチームを分離したくないマン - まっちゅーのチラ裏