マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte
研修中に「マイクロサービス」の解説をしていると,たまに「モノリス分割」に関する質問が出てディスカッションをすることがある.当然ながら万能な分割アプローチはないけど,例えば DDD (Domain-driven design) などのアプローチを選択するなど,選択肢はいろいろある.そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ. 具体的には以下の「計8種類」のアプローチが紹介されている.原著を翻訳するのではなく,あくまで個人的なメモとしてまとめる.なお,日本語も個人的に載せているため,参考程度にしてもらればと! Warm Up with a Simple and Fairly Decoupled Capability(シンプルかつ分離された機能で準
Platform Group, Platform Infra Team の @dtan4 です。 現在メルカリ/メルペイのマイクロサービス基盤 (Microservices Platform) では、様々なクラウドリソース・SaaS を開発者に提供しています。これらのリソースを宣言的に管理するための手段として HashiCorp Terraform を利用しており、数百のマイクロサービスのインフラが Terraform によって管理されています。 1年以上前の話ですが、Terraform 0.12 がリリースされました。昨年後半に、我々が管理している Terraform リポジトリにおいて Terraform 0.12 対応作業を行いました。本記事では、我々の環境においてどのように Terraform 0.12 対応作業を行ったかについて説明します。 Terraform 0.12 対応の動
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のサブドメ
今年もMercari Advent Calendar 2018 が始まりました。初日は @stanaka がお送りします。 メルカリでは創業以来開発してきたPHPのアプリケーションから(主に)Goで実装されたマイクロサービスアーキテクチャへの移行を進めています。これまでにMercari Tech Conferenceやその他のカンファレンスでMicroservice化の意義、移行の方法、基盤となるMicroservice Platformの概要などについて様々な発表をしてきました。 現在、来年からの本格的なマイクロサービスアーキテクチャでの開発に向けて、これまでのサービスの施策ドリブンのチーム編成から、マイクロサービスを軸としたチーム編成に移行しようとしています。 しかし、マイクロサービスアーキテクチャを成功させるためには、各種プラットフォームの機能を揃え、それらを利用したマイクロサービス
はじめに リアクティブシステムを構築するためのライブラリ「Akka」を開発する Lightbend社 から、リアクティブシステムやマイクロサービスについて学習できる有償のオンライントレーニング「Lightbend Academy」を提供されていますが、2020年夏の間(※)は無償で受講できるようになっています。 ※2020/07/14現在。当初は無償期間が6月末まででしたが、7月末 -> 夏いっぱいと期間が延長されています。 ※「Lightbend Academy」の受講については、こちらのスライド「Lightbend Academyオンライントレーニングを受けてみた」もご参照ください。 この記事では「Lightbend Academy」を受講して学んだ、リアクティブな性質を備えたマイクロサービスを設計・開発するために知っておきたい知識や理論 を、私なりに整理・再編してご紹介したいと思いま
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? tl; dr Envoyとgo-control-planeを利用すれば、そこそこ手軽にサービスメッシュを作ることができます。 ソースコードとサンプルはこちらにあります。 meshem: https://github.com/rerorero/meshem サービスメッシュとは サービスメッシュは、マイクロサービスが抱える問題を解決するためのアーキテクチャのひとつです。2017年にLinkerdを開発しているBuoyant社のCTOが使うようになり、広まったとされています。 What's a service mesh? And why d
株式会社ウルフチーフ 代表取締役。TIS株式会社にて19年半、さまざまな業種のシステムアーキテクチャ設計を担当し、2018年に退職、株式会社ウルフチーフを創業する。以降流しのアーキテクトとして、前職時代から書き溜めていたOSSプロダクトや技術記事を元に、様々な現場でアーキテクチャの設計や研修を実施している。 課題:リポジトリの肥大化に伴ってリリース頻度が低下 川島 freeeではどのような課題を解決するためにマイクロサービス化を検討されたのでしょうか? 横路 freeeのプロダクトの成り立ちからお話しすると、「会計freee」の最初のリリースが2013年で、翌年に「人事労務freee(当時の名称は給与計算freee)」をリリースしました。その段階で既に、各プロダクトや認証・認可を扱うサービス基盤などは、リポジトリやサービスを分割する形で開発・運用を行っていたんです。 しかし、プロダクトがマ
2020年7月15日に開催したFLEXY主催CTOmeetup。今回のテーマはインフラ戦略の最前線です。 登壇するのはDeNA、メルカリ、DMM、ミクシィの計4社のCTO及びVP of Backendのみなさん。 応募者多数、また登壇最中も質問がかなり寄せられる大人気イベントとなりました。 日本を代表するトップ技術者たちがインフラ戦略についてどのような考えを持っているのか、各社のインフラ事情も含めてオンラインで2時間ディスカッションしていただいている様子をライブ中継しました。 <パネラー> 株式会社メルカリ 執行役員 VP of Backend 田中 慎司 氏 合同会社DMM.com CTO 松本 勇気 氏 株式会社ミクシィ 取締役CTO 村瀬 龍馬 氏<モデレータ> 株式会社ディー・エヌ・エー 常務執行役員 兼 CTO 小林 篤 氏 登壇各社のインフラ事情Overview YouTube
本記事は、2019年8月21日に行われたmerpay社の主催するイベント、「Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~」の参加レポートです。 Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~ レポート セッションの概要 メルペイ社の認証基盤チームの担当している 外部向けに提供しているOIDCなどの認可の仕組み 内部のマイクロサービス間通信の認証の仕組み のうち、後者についてのお話を聞いてきました。セッションのスライドはこちらで公開されています。 チームがやっていること 認証基盤チームではユーザーアカウント管理とかログインはやってない 従業員の管理とかはやってない セキュリティについてはセキュリティチームと相談しながらやっている それ以外の認証認可を認証基盤チームがやっている 現状のアーキテクチャ
インフラストラクチャー部の青木峰郎です。 最近はDWH運用の傍ら、所属とまったく関係のないサービス開発のためのデザインスプリントをしつつ、 Java 10でgRPCサーバーを書きつつ、 リアクティブプログラミングを使った非同期オーケストレーション層を勢いだけで導入したりしています。 ですが今日はそれとはあまり関係なく、クックパッドの中核サービスであるレシピサービスの アーキテクチャ改善プロジェクト、「お台場プロジェクト」の戦略について話します。 これまで、お台場プロジェクトで行った施策について対外的に発表したことはあっても、 全体戦略について話したことはありませんでした。 その一番の理由は、正直に言って、プロジェクトオーナーであるわたしにもプロジェクト全体の姿が見えていなかったからです。 しかし現在プロジェクト開始から1年半が経過してようやく全貌が見えてきたので、すべてをお話ししようと思い
Microservices Platform TeamでTech leadをしている@deeeeeeetです. 昨年のMTC2018ではMicroservices Platformチームの立ち上げから1年で僕らが取り組んできたことを紹介しました. speakerdeck.com 具体的にはStranglerパターンによるMonolithからMicroservicesへの段階的なリクエスト移行を行うためのAPI gatewayの開発や,Microservicesのインフラのセットアップを簡単にしサービス開発チームのSelf-service化を進めるためのStarter-kitの開発,GoでのMicroservicesの開発を高速で始めるためのTemplateプロジェクトの開発,Spinnakerの導入などについて紹介しました. これらはPlatformとして最低限の機能を整備したにすぎず,さ
Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました! ぜひご覧いただけると幸いです! 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く