OpenTelemetry Meetup の登壇スライドです。 https://opentelemetry.connpass.com/event/296353/
ジョインしたチームのマイクロサービスたちを再計装した話 / Getting started tracing instrument micro service with OpenTelemetry
OpenTelemetry Meetup の登壇スライドです。 https://opentelemetry.connpass.com/event/296353/
この文書は、ある組織において、ある一つの Ruby on Rails で書かれたサービスの全部または一部を、(言語A) で書き直したい、という proposal に対して qsona が表明した意見の文を、一部手直ししたものです。このサービスは、現在担当しているチームとは別の人が初期実装をしたものであり、現在はまだ小規模ですが、今後新しいチームの手により発展していくもので、現在の規模のうちに要件や新しいチームメンバーに最適な言語で書き直すという選択は十分合理的です。また、この組織内のコードは、Ruby on Rails で書かれているものが大半であり、さらに組織としてマイクロサービスアーキテクチャの方向を目指している、という前提の上でお読みいただければと思います。もちろん文責は qsona 個人にあり、qsona の属する組織の意見とは関係ありません。 ------------------
[AWS Black Belt Online Seminar] AWSにおけるマイクロサービスアーキテクチャの設計パターン 資料及び QA 公開 | Amazon Web Services
Amazon Web Services ブログ [AWS Black Belt Online Seminar] AWSにおけるマイクロサービスアーキテクチャの設計パターン 資料及び QA 公開 先日 (2020/03/25) 開催しました AWS Black Belt Online Seminar「AWSにおけるマイクロサービスアーキテクチャの設計パターン」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200325 AWS Black Belt Online Seminar AWSにおけるマイクロサービスアーキテクチャの設計パターン AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. Amazon API Gateway は複数のバックエンドを統合する機能は持たないと思います。その意味で BFF パターンの実装に位
![[AWS Black Belt Online Seminar] AWSにおけるマイクロサービスアーキテクチャの設計パターン 資料及び QA 公開 | Amazon Web Services](https://cdn-ak-scissors.b.st-hatena.com/image/square/086852b76948f8957392ddb6df5e02bc042a3547/height=288;version=1;width=512/https%3A%2F%2Fd2908q01vomqb2.cloudfront.net%2Fb3f0c7f6bb763af1be91d9e74eabfeb199dc1f1f%2F2020%2F03%2F30%2FThumbnail-3.png)
モノリスからマイクロサービスへ-ZOZOBASEを支える発送システムリプレイスの取り組み - ZOZO TECH BLOG
はじめに こんにちは。基幹システム本部・物流開発部の岡本です。普段はZOZO基幹システムのリプレイスを担当しています。 ZOZOではさらなる成長のため、様々なリプレイスプロジェクトが進行しており、これまでにZOZOTOWNやWEARなどのプロダクトにおける多くのリプレイス事例を公開してきました。本記事では、2022年8月より本格始動したZOZO基幹システムリプレイスの第一弾であるZOZOの物流拠点「ZOZOBASE」を支える「発送システムリプレイス」を紹介します。「発送システムリプレイス」は設計を終えた開発段階で、リリースに向けて進行中です。本記事を皮切りに今後も継続的に発信を続けていくので、是非ご注目ください。 現状の「発送システム」は、Classic ASPのトランザクションスクリプトで実装された大規模なモノリス構成のシステムの一部であり、「障害リスク」と「開発速度の低下」に課題を抱え
CNDT2023 プレイベント 登壇資料
マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ - 赤帽エンジニアブログ
インテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 今回は レッドハットのシニアアーキテクトである Eric Murphy さんによる「マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ(CDC)」の翻訳記事です。この記事では、イベントソーシング、CDC、CDC + Outboxパターン、CQRSをそれぞれ簡単に説明しながら、それらの特性の違いを比較します。また、イベントソーシングとCQRSの簡易な説明がなされている他、あまり明確に語られることが少ないもののソフトウェアの設計に大きな影響をおよぼすドメインイベントとチェンジイベントの違いにも触れられています。 [原文] Distributed Data for Microservices — Event Sourcing vs. Change Data Captur
私が考えるマイクロサービスアーキテクチャ
はじめに 以前に、マイクロサービスアーキテクチャにゼロから挑んだ開発経験から、私が現時点で考えるマイクロサービスアーキテクチャを書いてみる。前回はAWSで構築したがAWSに限定せず汎用的に表現してみたいと思う。 前提 例として、社員の勤怠と有給の管理ができるようなwebのSaaSプロダクトを考える。 ここでいうプロダクトとは商品として販売できる最小の単位とする。 境界づけ まずは、プロダクトを5つの機能に分類する。 認証・・・認証を行うIdP。ユーザー固有のIDを管理するユーザーディレクティブを持つ。 ユーザー・・・認証されたユーザーと権限の紐付きを持つ。 権限・・・ロールとポリシーによる権限を設定する。「ユーザー」「権限」「勤怠」「有給」というサービスそれぞれに個別の設定ができる。 勤怠・・・勤務の開始と終了を管理できる。 有給・・・有給の付与、消化、残日数の管理ができる。 パターン1：
｜DMM inside
モノリスからマイクロサービスへ
本書は、モノリスからマイクロサービスアーキテクチャへと移行するための実践的なガイドです。マイクロサービスが自分たちのシステムに適しているかを判断するところから、ビジネスを維持しながらモノリシックなシステムを少しずつマイクロサービスに切り替えていく方法、さらには、マイクロサービスアーキテクチャが成長するにつれて起こる課題への対処の仕方まで、豊富な例やシナリオを用いて解説します。また、モノリスやデータベースを分解していくのに役立つ様々なパターンやテクニックも扱います。 システムのアーキテクチャ移行について具体的な方法を解説する本書は、エンジニア必携の一冊です。 はじめに 1章 必要十分なマイクロサービス 1.1 マイクロサービスとは 1.1.1 独立デプロイ可能性 1.1.2 ビジネスドメインに基づくモデル化 1.1.3 自分たちのデータを所有する 1.1.4 マイクロサービスがもたらす利点
このパターンには2つの背景があります。ひとつは、技術者がマイクロサービスアーキテクチャパターンを採用して、複数の(理想的には単一目的で、独立してデプロイ可能な)サービスで構成されるアプリケーションを開発するようになったことです。ふたつめは、企業がコンテナ(Dockerなど)、オーケストレータ(Kubernetesなど)、プロキシ/ゲートウェイ(Envoyなど)といった、クラウドネイティブなプラットフォームテクノロジを支持するようになったことです。 意図 サービスメッシュが解決しようとする問題は次のようなものです。 サービスディスカバリ、ルーティング、アプリケーションレベル(レイヤ7)の非機能通信要件を処理する言語対応の通信ライブラリを、個々のサービス用にコンパイルする必要性の排除 外部サービスのネットワークロケーション、セキュリティ認証、サービス品質(QoS)目標など、サービス通信設定の外
転職活動でいろんな会社のエンジニアの人と話して思ったことをマイクロサービスの観点で備忘録がてらメモしておく。 よくあるマイクロサービスの分割軸として、業務機能、ユースケース（動詞）、リソース（名詞）あたりが一般的だが、これらどれもがドメインを構成する要素であるため、マイクロサービスに分割してしまうと結果的にソフトウェアの形がビジネスルールの変化を制限してしまうケースの方が多い気がしていた。実際、規模の小さい開発組織でマイクロサービスやってみました〜からのツラミはそういうのが多いイメージで、よくある「マイクロサービスやったけど逆に開発遅くなった」みたいなとこは上で挙げたような粒度の切り方をしている印象がある。 この件に関して、去年末の転職活動のタイミングでいろいろな人に話聞いてみた結果、実際にマイクロサービスでうまくやっていそうな組織は、上で書いたようなドメインを構成する要素でマイクロサービ
メルペイのマイクロサービスの構築と運用 2019.07.22 に CloudNative Days Tokyo2019 で発表した内容です。 なぜメルペイがマイクロサービスアーキテクチャを選択したか、メルペイのマイクロサービスの構築と運用をどのように行ったか、などを話しました。
モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog
こんにちは。モノタロウのTechBlog編集チームです。 モノタロウではECサイトでのお客様体験の向上を目指して、日々改善に取り組んでいます。 商品の出荷目安などの出荷関連情報は重要な要素の1つになります。 今回は、出荷関連情報の正確性を改善するとともにシステムの変更容易性を向上させるためにマイクロサービス化に取り組んだ活動をインタビューしました。 自己紹介 納期表示を高度化する サプライヤ在庫連携機能開発のつらみ AVLのマイクロサービス開発のすすめ方 リリース・監視・その後の展開 おわりに 今回インタビューしたみなさん 自己紹介 山崎 章裕 ECシステムエンジニアリング部門 開発生産性グループ、プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム兼務 2019年8月に入社し、主にECサイトの注文・配送周りのプロジェクトにテックリードとして関わる。またECサイ
マイクロサービスを蝕む負の力学
マイクロサービスを蝕む負の力学 マイクロサービスアーキテクチャでは、全体を分割し小さいチームとサービスにすることでチームの責任範囲を小さくし、 限られた範囲内で独自にPDCAを回すことで人数の拡大に対しても生産性を落とさないのが利点の一つになります。 これにより個々のマイクロサービスの関心事は小さく保たれるため、構成はシンプルになり実装しやすくなります。 一方でサービス間の依存関係が複雑になったり、通信量コストがとても増えるといったサービス間をまたいだところへの問題、 データの整合性や分散コンピューティングの落とし穴といった分散システム特有の問題、通信先のマイクロサービスの信頼性、安定性といった問題など、マイクロサービスアーキテクチャ全体としての複雑性は上がります。 そして、こういった複雑性や一部のマイクロサービスの不安定さは、そのマイクロサービスを構成する全員に悪影響を与えます。 つまり
カオスエンジニアリングを導入したクックパッドの挑戦 マイクロサービス化に伴う可用性の低下に対応 - エンジニアHub｜Webエンジニアのキャリアを考える！
カオスエンジニアリングを導入したクックパッドの挑戦 マイクロサービス化に伴う可用性の低下に対応 料理のレシピ投稿・検索サービスのクックパッドでは2年前からカオスエンジニアリングに取り組み、さまざまな事例やノウハウを蓄積しています。クックパッドの技術部・SR（Site Reliability）グループの小杉山拓弥さんとDX（Developer Productivity）グループの鈴木康平さんに、導入の理由やさまざまな知見を伺いました。 カオスエンジニアリング（Chaos Engineering）とは、稼働中のサービスにあえて擬似的な障害を発生させることで、システムの耐障害性を検証する手法です。動画配信サービスを提供するNetflix社が2011年ごろから実践し、ソフトウェアや情報を積極的に公開したことで世界中から注目されるようになりました。 国内ではまだ導入事例も少ないなか、料理のレシピ投稿
マイクロサービス・アーキテクチャ(MSA)を適用する際に頭を悩ます問題のひとつが「複数サービスにわたる更新操作」である。マイクロサービスを成すソフトウエアのまとまりは、個々に独自のデータストアを持っている。ゆえに複数サービスを横断する更新操作の際、トランザクション管理によるACID特性を保証できなくなる。 この問題に対処するために二相コミットや結果整合性等の考え方があるが、どのやり方でも限界があるし、ある種の制約や余分な手間を受け入れざるを得ない。もっとも穏当な設計方針は「複数サービスに渡る更新が起こるような粒度ではサービスを切り出さない」である。個々のサービスを実装する段になって悩む前に、サービス粒度の設計に関して事前に考慮すべきことがあるということだ。 前回記事で説明した「CRUD基準によるサブシステム分割」は、更新制御の面から見たサービス粒度の設計基準として応用できる。ドメイン駆動設
BacklogのSREを担当しているmuziです。 今回の記事では、ヌーラボにおけるSREの活動事例として、Backlogの課題検索機能のリプレイスプロジェクトについてご紹介します。 このプロジェクトでは、SREと開発者がチームを組んで、要件定義からリリースまで行いました。その結果、Backlogを構成するサーバ同士が疎結合になり、将来的なマイクロサービス化に向けた足がかりを作ることができました。 歴史の長いプロダクトにありがちな技術的負債への取り組みの一例として、みなさんの参考になれば幸いです。 リプレイスプロジェクトの背景 Backlogの課題検索機能 最初に、このリプレイスプロジェクトの背景として、Backlogの課題検索機能についてご紹介します。 課題検索機能とは、Backlogの「課題」ページで利用できる検索機能のことです。件名や詳細に対するキーワード検索に加えて、プレミアムプラ
LINE株式会社 古田 大志 京都開発室 / 出前館マーチャント部 クーポンサービス チームリード 2023.9.12「モジュラモノリス徹底解剖vol.2〜実践者から学ぶLunch LT〜」の登壇資料です https://findy.connpass.com/event/293748/
N予備校のバックエンドは、2016年のリリース当初からマイクロサービスアーキテクチャを採用しています。 この記事では、N予備校のマイクロサービスアーキテクチャについて、主にアプリケーション側の観点からご紹介していきます！ 目次 目次 N予備校の全体構成 なぜマイクロサービスにしたか？ 採用しているマイクロサービスのデザインパターン Decomposition/サービスの分割 Data management/データ管理 External API/外部API, Orchestration/オーケストレーション Communication/コミュニケーション Deployment/デプロイ, Service discovery/サービスディスカバリ 利用しているフレームワーク/サービス マイクロサービスの運用の難しさと今後の展望 課題: 責務の分割へのハードル 今後の改善方針 We are hi
マイクロサービスの開発とテストファースト／テスト駆動開発 【Mercari Gears Lecture Series】 | メルカリエンジニアリング
こんにちは、Mercari Gears事務局です！ この記事では、動画公開以来とても反響のある Mercari Gears Lecture Series #47〜#49「マイクロサービスの開発とテストファースト／テスト駆動開発」の動画の内容を記事に起こしたものです。 今回の実際の動画はこちらになります、興味があればぜひご覧ください！ MERCARI GEARS Lecture Seriesとは？ MERCARI GEARS Lecture Seriesは、株式会社メルカリをはじめとするメルカリグループ各社が、これから目指す方向や、これから取り組む技術的なチャレンジについてご紹介するエンジニア向けのレクチャー動画シリーズです。 MERCARI GEARS Lecture Series お話する人の自己紹介 株式会社メルペイ 柴田芳樹 九州工業大学 情報工学修士 1984年 富士ゼロックス 入
Kimihiko KitaseHead of Enterprise Marketing, Google Cloud Japan デモ用のマイクロサービスアプリケーションを使って実際に、マイクロサービスアプリケーションの開発、ビルド、デプロイ、運用を体験してみましょう。 このアプリケーションは、10 のサービスで構成されている「Hipster Shop」と呼ばれるデモ用の EC サイトです。ユーザーは、製品を選択し、カートに追加し購入することができます。各サービスは、Go, C#, Node.js, Python, Java といった言語で独自に書かれおり、下記のように、gRPC でコミュニケーションします。また、開発者は skaffold を使用し、1 コマンドでアプリケーションのビルド、デプロイが可能です。実行環境は、Google Kubernetes Engine (GKE) や、Lo
開発と運用の理想的な関係とはどんな姿か。すでに「DevOps」という言葉は浸透しているものの、理想的な形で実践できているかとなると、話は別だ。現場ではどんな障壁があり、DevとOpsが分断されているのか。打開していくにはどうしたらいいのか。DevOpsという言葉が生まれる前から、その本質を実践してきたAmazonのカルチャーにヒントがありそうだ。AWSジャパン 塚田朗弘氏に聞いた。 今回お話を伺った、アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 塚田朗弘氏 ペアで語られてしまいがちな「マイクロサービス」と「コンテナ」 Amazonには「DevOps」や「マイクロサービス」という言葉が生まれる前から、DevとOpsを統合し、システムはAPIでやりとりするという原則がある。それを長年追求するなかで、開発カルチャーを育んできた。そんなAmazonから開発と運用の理想の
この記事はGLOBIS Advent Calendar 2020の9日目の記事です。 こんにちは、@yohira_devです。 数年前からグロービスの開発案件に参画させていただいています。「智将は務めて敵に食む」という言葉がありますが、今回はグロービスのAdventCalanderで記事を書かせていただきます。 今回のAdventCalanderでは、「モノリスからマイクロサービスへの設計の切り替え方」について、書いていきたいと思います。 この記事を読むべき人 「マイクロサービスってなんか良さそう！うちもとりあえず導入してみようかな...」と思っている人 モノリスでは起こらなかったデータ不整合に消耗している人 モノリシックアプリケーションとマイクロサービスの違い モノリシックなWebアプリケーションを書いている感じで「手なりで」マイクロサービスを実装すると思わぬ落とし穴に嵌ることがあります
freee の権限管理基盤マイクロサービスの今を語ろう！ - freee Developers Hub
はじめに こんにちは、freee の 権限管理基盤マイクロサービスを開発するチームでエンジニアリングマネージャーを務めている sentokun と申します。前職ではできることをできる限りやろうというスタンスで開発チームをリードし、アーキテクチャ設計やチームビルディングなどに取り組んでいました。その後 2022 年に freee へ入社し、freee で初めてエンジニアリングマネージャーの役割に。変わらずできることにできる限り取り組むスタンスでチームビルディングに従事しています。 この記事では、我々のチームが担当している権限管理基盤について語っていこうと思います！ 権限管理基盤の成り立ち freee では、「スモールビジネスを、世界の主役に。」をミッションに掲げ、統合型経営プラットフォームの開発・提供を進めています。最近では freee Togo Panorama を公開するなど、統合に向け
マイクロサービスの課題を解決する手段の一つとしてサービスメッシュが注目を集めている。だが、注目を集め過ぎるあまり、サービスメッシュを唯一の選択肢と考えてしまうきらいもある。そうした傾向に対し、「サービスメッシュが本当に必要なのかどうかについて、一度原点に立ち返って考えることが重要です」と説くのは、アマゾンウェブサービスジャパン シニアコンテナスペシャリスト ソリューションアーキテクト Hara Tori氏だ。 「Developers Summit 2020」に「サービスメッシュは本当に必要なのか、何を解決するのか」と題して登壇したHara Tori氏は、講演の中で「サービスメッシュはなぜ必要なのか」「何を解決してくれるのか」について、1つのサービスが成長していく姿になぞらえながら解説していった。 そもそも「モノリス」って何だ？ まず、何かのプロダクトやサービスを開発する場合、基本となるのは
Goの初心者から上級者までが1年間の学びを共有する勉強会、「GeekGig #1 ～Goと私の一年～」。ここで株式会社Showcase Gigの高橋氏が登壇。マイクロサービスセキュリティの難しい点と、認証認可の実施方法を紹介します。 自己紹介 高橋建太氏（以下:高橋）：「認証認可とGo」について説明します。まず自己紹介です。現在Showcase GigのPlatformチームに所属しています。主に認証認可の機能を担当しています。高橋建太です。 週1回会社でGoの知見を共有したり、ドキュメントを読んだり、Goについてみんなで話す緩い勉強会を主催で開催しています。もし合同で勉強会やりたい方がいれば、気軽に連絡してください。ぜひやりましょう。 「O:der」について まず前提知識として、「O:derとは？」について、あらためて説明します。ちょっと内部寄りな説明となり、実際のものは若干スライドの図
この記事は、マネフォアドベントカレンダー2022 14日目の投稿です。 13日目は 廣瀬 さんで「チーム運営の仮説検証サイクルを高速化させるために、新卒スクラムマスターが取り組んだこと」でした。 本日は 岐阜在住で名古屋開発拠点のsainu が「マネーフォワードで実践したマイクロフロントエンド」について書きたいと思います。 はじめに マイクロフロントエンドは、2022年10月にBuilding Micro-Frontends（Luca Mezzalira 著）の翻訳版がオライリーから出版されて少し話題になってました。ThroughWorks Technology Radarには2016年から登場して、2019年にAdoptになっています。 私は今年の年初にマイクロフロントエンドという言葉を初めて知りました。今年、名古屋拠点で開発しているマネーフォワードクラウドの業務基盤システムでマイクロフ
デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう！アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。 「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。 なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。 「今まで」と「これから」のギャップ 失敗1：半島型 新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕
こんにちは。ソウゾウのSoftware Engineerの@napoliです。連載：「メルカリShops」プレオープンまでの開発の裏側の3日目を担当させていただきます。 メルカリShopsではマイクロサービスアーキテクチャによる開発を採用しています。ここではメルカリShopsではどのようにマイクロサービスと向き合っているかを紹介させていただきます。 メルカリShopsのマイクロサービス群 メルカリShopsはざっくりと、図のような形でマイクロサービス群が構成されています。 Frontendがひとつ、Backend For Frontend(BFF)がひとつ、そして(執筆時点で)約40ほどのBackendサービスが、それぞれが独立した実行環境で稼働しています。 BackendはShop(ショップ)、Product(商品)、Order(注文)、Payment(決済)といったドメインごとに独立し
Sansan Technical Viewは「挑戦」をテーマにSansanエンジニア達の開発における取り組みや知見を発表するイベント。Bill One事業部のソフトウェアエンジニアである加藤氏がマイクロサービスへの取り組みを紹介しました。発表資料はこちら。 Bill Oneでのマイクロサービスの取り組み 加藤耕太氏：こんにちは。加藤です。今日は『新規事業でもマイクロサービスに挑戦する』というタイトルでお話しします。マイクロサービスアーキテクチャについてご存知の方は、新規サービスをマイクロサービスで作るのはアンチパターンである、という話を聞いたことがあるかもしれません。 チームが小さいにもかかわらず流行りに乗ってマイクロサービスに分割して作ってみたものの、開発の効率が落ちるだけでしたとか、独立してデプロイできない分散モノリスができあがってしまいました、のような失敗談を聞くことがあります。 新
ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキルのスライド / DDD session slide in AWS Dev Day Online Japan 2021
AWS Dev Day Online Japan 2021 のパネルディスカッション 『ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル』 で利用したスライドです 自己紹介→マイクロサービスでどうしてDDD？→学習ルート # URL AWS Dev Day Online Japan 2021: https://aws.amazon.com/jp/about-aws/events/2021/devday/ YouTube: https://www.youtube.com/c/narusemi HomePage: https://nrslib.com Twitter: https://twitter.com/nrslib
ガートナーの米国本社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、＠IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。 Gartnerが行ったソーシャルメディア分析調査によると、2019年1月から2020年9月までの間に、「マイクロサービスアーキテクチャ」への言及数は42％減少した。 この傾向は、マイクロサービスアーキテクチャへの幻滅の高まりを示している。マイクロサービスアーキテクチャは、サービス指向アーキテクチャとドメイン駆動設計原理を分散アプリケーション――つまり、マイクロサービスに適用することで、アジリティ（開発の迅速性）、デプロイ（展開）の柔軟性、きめ細かいスケー
はじめに こんにちは、 @stanaka です。メルカリではいまビジネス基盤強化を進めるプロジェクト「Robust Foundation for Speed」を立ちあげていますが、このプロジェクトの前段となっているマイクロサービスマイグレーションについて、その理想と現実について紹介します。 モダンな開発チームのあるべき姿 まず理想を語る上で、ここ数年のエンジニア組織の改善や生産性向上の議論をいくつか見てみます。開発チームとアーキテクチャについては、以下の2点がよく重視されています。 開発のイテレーションを加速するために、チームがオーナーシップを持つサービス/システムについて設計から開発、運用までの責任を開発チームが負う 認知的負荷(cognitive load)を許容範囲に抑えるために、システムを疎結合化し他チームへの依存を減らす設計を行う 設計から開発、運用までの責任を開発チームが負う
はじめに 前篇の「リアクティブマイクロサービス入門（1/2）- 概念編」では、なぜリアクティブマイクロサービスが必要なのか、リアクティブマイクロサービスとは何なのかをご紹介しました。 後編となるこの記事では、リアクティブマイクロサービスの実装するために使えるテクニック・技術を、目的別にご紹介します。 もちろん、これらすべてを盛り込まなければリアクティブマイクロサービスを実現できないわけではありませんが、引き出しとして知っておけばより柔軟な設計ができるのではないかと思います。 目的別にまとめているので、適宜リファレンス的にご参照いただければと思います。 モジュール化 リアクティブマイクロサービスに求められる性質をバランス良く満たすためには、ビジネス上の関心事を分割することが重要です。 トレードオフで同時に実現することが難しい要件でも、分割することでそれぞれの関心時に最適化した手段を選択して実
レッドハットでインテグレーションのためのミドルウェアのテクニカルサポートを担当している山下です。以前、SAGAやEventStormingについて記述すると宣言していたのですが、実際のところ私が書くよりもよっぽど良い日本語の書籍や記事がでていて、もう書く必要もないと思っていたのですが、今回機会をいただいたので約４年ぶりに”マイクロサービスとメッセージングのなぜ"の希望編を書くことになりました。今回の記事ではSAGAやEventStormingの詳細は書かないのですが、私がイベントやメッセージングが必要と考えるに至った危機感や希望を共有します。そうした意味ではむしろ原点ともいえる内容になっています。なお今回記事にはとりわけ個人的な経験や意見が多く含まれますので、事前に異論は認めることにします。 以前の記事はこちら： 「マイクロサービスとメッセージングのなぜ [概要編]」 「マイクロサービスと
![マイクロサービスとメッセージングのなぜ [希望編] - 赤帽エンジニアブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/b23d4fe2216c99e2d9695c6dfa89ca7dfbabcf5b/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Ft%2Ftyamashi-oss%2F20231218%2F20231218002927.jpg)
マイクロサービスに失敗する7つの方法
次の問題は、CV駆動開発(CV-driven development)です。自分のCV(Curriculum Vitae、職務経歴書)を見ます。すると、"マイクロサービス"に関する部分が大きく空いていることに気付きます。これでは都合が悪いので、"自社のスタックを再構築して解決しよう"、と考えるのです — 読者の皆さんは、"Holly、それは皮肉が過ぎるよ"、と思うかも知れません。"自分の履歴書の都合でアーキテクチャを決めるやつがどこにいるんだ？" それが実は ... いるのです。 Red Hatは先日、コンテナベース開発を導入したおもな動機に関する調査を行いました。その結果、最も多かったものは"キャリアアップ"でした。"キャリアアップ"は、CV駆動開発の体のよい言い換えに過ぎません。 現在のマイクロサービスは"新正統派"と言ってもいいものですから、経歴書にマイクロサービスが欠けているのは大
はじめに リアクティブシステムを構築するためのライブラリ「Akka」を開発する Lightbend社 から、リアクティブシステムやマイクロサービスについて学習できる有償のオンライントレーニング「Lightbend Academy」を提供されていますが、2020年夏の間（※）は無償で受講できるようになっています。 ※2020/07/14現在。当初は無償期間が6月末まででしたが、7月末 -> 夏いっぱいと期間が延長されています。 ※「Lightbend Academy」の受講については、こちらのスライド「Lightbend Academyオンライントレーニングを受けてみた」もご参照ください。 この記事では「Lightbend Academy」を受講して学んだ、リアクティブな性質を備えたマイクロサービスを設計・開発するために知っておきたい知識や理論 を、私なりに整理・再編してご紹介したいと思いま
AWS Dev Day 2022 Japan の発表資料です。
どうも、エンジニアの神 id:pikatenor です。書きかけの記事を下書きに突っ込んで放置していたらマネージャーの常松に目をつけられ、#Rettyマイクロサービス強化月間 第1週目の記事に祭り上げられることになりましたが無事に遅刻しました。記事の公開をお待ちいただいていた皆様には深くお詫び申し上げます。 engineer.retty.me そういうわけで今回は自作OSSの宣伝とそいつをサービスに組み込むに至った背景のお話です。 マイクロサービスのDB分割と集約 Logstash + gRPC という選択 大雑把な説明 gRPC Server 側の実装 良かったこと おまけ: プラグインの実装についてあれこれ マイクロサービスのDB分割と集約 さて、Retty がマイクロサービスアーキテクチャへの移行に取り組んでいるという話は従前の通りですが、最近では共有DBの呪いから解き放たれるべくD
急成長中のスタートアップ企業は、多様なAWSサービスをどう選択・活用し、ビジネス課題を解決しているのでしょうか。本連載では、スタートアップ企業の中でエンジニアリングをリードしている担当者がそのアーキテクチャをひも解き、AWS活用術を紹介していきます。第3回はfreeeのSREエンジニア藤原峻輝氏が担当、テーマは「コンテナ（Kubernetes）」です。記事の最後には、SAによるポイント解説もあります。（編集部） はじめに はじめまして、freee株式会社でSRE（Site Reliability Engineering）をしている藤原峻輝と申します（各種id：@renjikari）。SREはその名が示す通りサイトの信頼性向上を目指すロールであり、freee全体のサービスの信頼性をあげるために、障害対応の運用から新しいインフラ基盤を開発することまで担当しています。 freeeについて fre
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロサービスを (Ruby on Rails 以外の任意の言語) で書くことについての意見｜qsona
Kafka Streamsで作る10万rpsを支えるイベント駆動マイクロサービス
社内で提供しているマイクロサービスの参考実装について - DMM inside
サービスメッシュ必読ガイド - マイクロサービス時代のサービス間通信管理
転職活動でいろんな会社のマイクロサービスと組織を見聞きして思ったこと - Runner in the High
メルペイのマイクロサービスの構築と運用 / CloudNative Days Tokyo2019
業務システムとマイクロサービス（２） - 設計者の発言
SREの活動事例紹介 〜 Backlogのマイクロサービス化に向けた課題検索機能のリプレイス
マイクロサービスにおけるBFFアーキテクチャでのモジュラモノリスの導入
N予備校のマイクロサービス - ドワンゴ教育サービス開発者ブログ
体験して理解しよう！マイクロサービスの開発、ビルド、デプロイ、運用 | Google Cloud 公式ブログ
マイクロサービスの失敗は技術だけの問題か――Amazonに学ぶ開発・運用組織の理想形とは
モノリスからマイクロサービスへの設計の切り替え方 - Qiita
そのモノリス、本当にマイクロサービス化が必要？ サービスメッシュも？
マイクロサービスセキュリティの「7つの難しさ」とその対応策 Open ID ConnectとSDKの実装で認証認可の安全性を担保
マイクロサービスのその先へ。マネーフォワードのビジネスを加速するマイクロフロントエンドという選択
アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp
メルカリShopsはマイクロサービスとどう向き合っているか | メルカリエンジニアリング
Sansanの「Bill One」がマイクロサービス化に挑戦した理由 ある程度方向性が見えてきてからサービスは分割すべき
マイクロサービスアーキテクチャを、あなたの開発チームは本当に使うべきなのか
メルカリにおけるマイクロサービスマイグレーションの理想と現実 | メルカリエンジニアリング
リアクティブマイクロサービス入門（2/2）- 実現編 - Qiita
マイクロサービスとメッセージングのなぜ [希望編] - 赤帽エンジニアブログ
リアクティブマイクロサービス入門（1/2）- 概念編 - Qiita
DMMプラットフォームのマイクロサービス戦略 オーナーシップの落とし穴
マイクロサービスのデータぜんぶ抜く……gRPCで！ - Retty Tech Blog
急成長のfreeeに学ぶ、進化するアーキテクチャ――Kubernetes×AWSで複雑化したマイクロサービス基盤を改善