InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architects. View an example
レッドハットでインテグレーションのためのミドルウェアのテクニカルサポートを担当している山下です。以前、SAGAやEventStormingについて記述すると宣言していたのですが、実際のところ私が書くよりもよっぽど良い日本語の書籍や記事がでていて、もう書く必要もないと思っていたのですが、今回機会をいただいたので約４年ぶりに”マイクロサービスとメッセージングのなぜ"の希望編を書くことになりました。今回の記事ではSAGAやEventStormingの詳細は書かないのですが、私がイベントやメッセージングが必要と考えるに至った危機感や希望を共有します。そうした意味ではむしろ原点ともいえる内容になっています。なお今回記事にはとりわけ個人的な経験や意見が多く含まれますので、事前に異論は認めることにします。 以前の記事はこちら： 「マイクロサービスとメッセージングのなぜ [概要編]」 「マイクロサービスと
はじめに この記事は、AEON Advent Calendar 2023の21日目です🎉 イオンスマートテクノロジー株式会社（通称AST）のCTO室TechLeadチームの@t0doroki_takaです。弊社ではSREチームの発信に勢いがありますが、アプリケーションレイヤーよりの話題も積極的に発信していければと思います。 自分の敗戦の振り返り 以前、大規模ECシステムのリプレース案件に関わった時(そして敗戦したとき)の振り返りです。 今回取り上げるケーススタディは、システム全体(連係するシステム含む)としては段階的移行ではありましたが、主ターゲットとなるシステムは、全EC機能を包括する大規模なシステムで、それをフルスクラッチでリプレースするものでした。 巨大なモノリス構造であったため、マイクロサービスアーキテクチャに移行することで、サービス提供のアジリティを確保することが目的の一つでし
マイクロサービスアーキテクチャにおいては、個々が独立に選定したデータベースを持つ複数のサービスにまたがって、データの整合性を維持する必要があります。 そのための方法として、Sagaパターンと呼ばれる設計方法がありますが、Sagaでは分離性が欠如しておりLost Update等の異常が発生しかねません。 そこで本記事では、Sagaの分離性を高めるための実装におけるTipsを解説します。 目次 目次 はじめに 複数サービス間での整合性維持における課題 Sagaパターン Sagaを構成するトランザクション Sagaによって実現される安全性 原子性（Atomicity） 整合性（Consistency） 分離性（Isolation） 永続性（Durability） 異常を防止/軽減する実装 分離性の欠如が引き起こす異常 分離性の欠如への対策 Semantic Lock Commutative Up
Author: @urahiroshi, Engineering manager of Web Platform team 2022年8月4日、メルカリで “web-2” と呼ばれるサーバがシャットダウンされました。これはメルカリWeb版の開発に携わっているチームにとって、一つの区切りとなる出来事でした。 web-2はPHPで記述されたwebサーバで、2015年から https://www.mercari.com/jp/ 配下のコンテンツを配信していましたが、現在では複数のWebマイクロサービスがその機能を担っており、 https://www.mercari.com/jp/ 配下のページは後継となるWebマイクロサービスが配信するページへリダイレクトされています。 メルカリWebのマイクロサービス化に向けた開発が始まり、最終的にweb-2がシャットダウンされるまで、実に4年以上の期間がかか
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of two or more services that are: Independently deployable Loosely coupled Services are typically organized around business capabilities. Each service is often owned by a single, small team. For a business to thrive in today’s volatile, uncertain, complex and ambig
本書は、モノリスからマイクロサービスアーキテクチャへと移行するための実践的なガイドです。マイクロサービスが自分たちのシステムに適しているかを判断するところから、ビジネスを維持しながらモノリシックなシステムを少しずつマイクロサービスに切り替えていく方法、さらには、マイクロサービスアーキテクチャが成長するにつれて起こる課題への対処の仕方まで、豊富な例やシナリオを用いて解説します。また、モノリスやデータベースを分解していくのに役立つ様々なパターンやテクニックも扱います。 システムのアーキテクチャ移行について具体的な方法を解説する本書は、エンジニア必携の一冊です。 はじめに 1章 必要十分なマイクロサービス 1.1 マイクロサービスとは 1.1.1 独立デプロイ可能性 1.1.2 ビジネスドメインに基づくモデル化 1.1.3 自分たちのデータを所有する 1.1.4 マイクロサービスがもたらす利点
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、Yahoo!ショッピングでシステム開発を担当している石田と村上です。 Yahoo!ショッピングでは数億件にのぼる商品が日々更新されています。 今回はそれを支える出品ツールをマイクロサービス化して解決した課題と、複数のチームで開発する中で課題に感じたことを紹介します。 出品ツール（ストアエディタ）について マイクロサービス化の話に入る前に、まずはYahoo!ショッピングの出品ツール（ストアエディタ）について紹介します。 ストアエディタとは、出店ストアの方々がYahoo!ショッピングに出品するためのツールです。 出品データは以下の図にあるフローで連携されます。 商品情報には以下の情報が含まれており、入稿された値が正しいかど
自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える
GraphQL Tokyo #10 Links: p11 https://speakerdeck.com/qsona/graphql-for-service-to-service-communication-protocol p12 https://note.com/qsona/n/nfc73a8…
複数のクラウドサービスを利用している（マルチクラウド）など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
このパターンには2つの背景があります。ひとつは、技術者がマイクロサービスアーキテクチャパターンを採用して、複数の(理想的には単一目的で、独立してデプロイ可能な)サービスで構成されるアプリケーションを開発するようになったことです。ふたつめは、企業がコンテナ(Dockerなど)、オーケストレータ(Kubernetesなど)、プロキシ/ゲートウェイ(Envoyなど)といった、クラウドネイティブなプラットフォームテクノロジを支持するようになったことです。 意図 サービスメッシュが解決しようとする問題は次のようなものです。 サービスディスカバリ、ルーティング、アプリケーションレベル(レイヤ7)の非機能通信要件を処理する言語対応の通信ライブラリを、個々のサービス用にコンパイルする必要性の排除 外部サービスのネットワークロケーション、セキュリティ認証、サービス品質(QoS)目標など、サービス通信設定の外
こんにちは、プラットフォームチームの池田と申します。初投稿です。 プラットフォームチームではマイクロサービスアーキテクチャの構成を採用し開発を進めています。 どんな構成でも忘れてはいけないのがロギング。いわゆる非機能要件の1つで地味な存在ですが、サービス運用を支える上で非常に重要です。 直近でマイクロサービスにおけるロギングの構成を調査し、プラットフォームチームでメインで採用しているGo言語での実装を検証しました。 今回の記事ではそのまとめを紹介します。 目次 目次 ロギングベストプラクティス for マイクロサービス リクエストにユニークなIDを付与し紐付けができるようにする ログは一箇所に集める ログデータを構造化する ログに有益な情報を持たせる どのサービスでも共通で持つのが望ましいフィールド リクエストのエントリーポイントとなるサービスで持つのが望ましいフィールド Go言語での実装
CloudNative Days Kansai 2019のキーノートの資料です
メルカリ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のマイクロサ
ふくおかFGのネット銀行、勘定系システムに「Google Cloud Platform」採用 開発スピード迅速化 福岡銀行などを傘下に持つ金融持ち株会社、ふくおかフィナンシャルグループ（FG）は9月24日、2020年度中をめどに開業予定のインターネット専業銀行「みんなの銀行」（仮称）の勘定系システムの基盤に、Google Cloud Platform（GCP）を採用すると発表した。開発・運用コストを抑え、外部サービスとの連携をしやすくする狙いがある。 勘定系システムの開発では、預金、為替といった個々の金融機能を独立したサービスとして開発し、APIなどで連携して1つのアプリケーションにする「マイクロサービスアーキテクチャ」という手法を採用する方針。GCPはそうしたマイクロサービスの稼働に適していると判断し、導入を決めたという。 システム開発を担当するふくおかFG傘下のゼロバンク・デザインファ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く