マイクロサービスセキュリティの「7つの難しさ」とその対応策 Open ID ConnectとSDKの実装で認証認可の安全性を担保
Goの初心者から上級者までが1年間の学びを共有する勉強会、「GeekGig #1 ～Goと私の一年～」。ここで株式会社Showcase Gigの高橋氏が登壇。マイクロサービスセキュリティの難しい点と、認証認可の実施方法を紹介します。 自己紹介 高橋建太氏（以下:高橋）：「認証認可とGo」について説明します。まず自己紹介です。現在Showcase GigのPlatformチームに所属しています。主に認証認可の機能を担当しています。高橋建太です。 週1回会社でGoの知見を共有したり、ドキュメントを読んだり、Goについてみんなで話す緩い勉強会を主催で開催しています。もし合同で勉強会やりたい方がいれば、気軽に連絡してください。ぜひやりましょう。 「O:der」について まず前提知識として、「O:derとは？」について、あらためて説明します。ちょっと内部寄りな説明となり、実際のものは若干スライドの図
マイクロサービスの開発とテストファースト／テスト駆動開発 【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年 富士ゼロックス 入
なぜマイクロサービスは失敗するのか? - kawasima
Eberhard Wolffさんのこのプレゼンの要約です https://www.youtube.com/watch?v=B3O-qYM-Kkw 共通のデータモデル 共通のデータモデルを通信に使う 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、す
マイクロサービスを形式的に見てみる - Juju-62q's blog
マイクロサービスについて考えていたら疲弊したので、少し技術者らしく形式的に見てダメのものを思考から削ぎ落としたいと思った。 グラフ理論などコンピュータサイエンスの基礎を交えて話をするが、基本的には当たり前のことしか言わないと思うのでここに書くことを意識せずとも暗黙的に実践している人も多いだろう。 なお、個人の意見でしかないのであっているか間違っているかはわからないし、筆者にこの記述に反した実装を否定する意図はない。 今回は適当に書き散らかすのでかなりテイストが違うが他のブログと同一人物が書いている。乗っ取り等ではないです。 TL;DR マイクロサービスはDAGとすると考えやすいしデプロイしやすい 閉路があるなら設計を見直した方がいい DAGかどうかはサブシステムレベルでそれぞれ考えると簡単 デプロイに関係するリポジトリでは閉路がないことを意識させる設計にするといい マイクロサービスと疲弊
メルペイのマイクロサービスアーキテクチャの裏側と、不整合を防ぐための工夫
2019年7月24日、ヤフー株式会社が主催するサーバーサイドエンジニア向けの勉強会「Bonfire Backend #3」が開催されました。第3回となる今回のテーマは「モバイル決済の裏側」。急速に成長するモバイル決済分野でサービスを展開する企業が一堂に会し、自社サービスの仕組みや技術スタックなど、知られざる裏側を語ります。プレゼンテーション「静的MPM決済を支える技術 」に登壇したのは、株式会社メルペイのsusho氏。今年の6月にサービスが開始したばかりのメルペイのサーバーサイドの特徴と工夫について語ります。 静的MPM決済を支える技術 susho氏：こんばんは。「静的MPM決済を支える技術」ということでsushoが発表させていただきます。 最初に自己紹介です。 社内ではsushoと呼ばれているので、ここでもそうさせていただいております。Twitterは@susho0220でやっています。
マイクロサービスを蝕む負の力学
マイクロサービスを蝕む負の力学 マイクロサービスアーキテクチャでは、全体を分割し小さいチームとサービスにすることでチームの責任範囲を小さくし、 限られた範囲内で独自にPDCAを回すことで人数の拡大に対しても生産性を落とさないのが利点の一つになります。 これにより個々のマイクロサービスの関心事は小さく保たれるため、構成はシンプルになり実装しやすくなります。 一方でサービス間の依存関係が複雑になったり、通信量コストがとても増えるといったサービス間をまたいだところへの問題、 データの整合性や分散コンピューティングの落とし穴といった分散システム特有の問題、通信先のマイクロサービスの信頼性、安定性といった問題など、マイクロサービスアーキテクチャ全体としての複雑性は上がります。 そして、こういった複雑性や一部のマイクロサービスの不安定さは、そのマイクロサービスを構成する全員に悪影響を与えます。 つまり
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
マイクロサービス ４つの分割アプローチ
アプリケーションの分割のアプローチ ●４つのアプローチ - ビジネスファンクション - 動詞／ユースケース - 名詞／リソース - 境界づけられたコンテキスト ● トランザクションの分割 - パイプライン化 (VETRO) - コーディネート (Saga) - 状態更新の非同期化 ( Event History - State Materialize - Domain Specific Query ) Read less
Microservicesでなぜ作るのか - An Epicurean
「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流
マイクロサービスのデザインパターン
第1版 2015年9月21日 第2版 2015年12月24日 Bluemixでは，たくさんのサービスやAPIが提供されており，それらを組み合わせることでアプリケーションを開発することができます．単一のプログラム言語を使って，多数のライブラリやクラスファイルを結合して作る大きなアプリケーションにももちろん利点がありますが，新しい機能やUXを継続的に提供したい時や，目的に合わせてプログラミング言語やデータベースを選択したい場合には，それぞれが独立したサービスを組み合わせるやり方が有利です．この考え方の根底にあるのが，James LewisとMartin Fowlerが提唱しているマイクロサービスです．彼らのブログ記事にあるマイクロサービスの定義にあたる部分を訳してみました． マイクロサービス(Microservices)アーキテクチャスタイルは、それぞれが独立のプロセスで実行され，HTTPリソ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロサービス・アーキテクチャと共存する Ruby on Rails のアーキテクチャ的拡張 - その事例と可能性 / Kaigi on Rails 2021
Webサービスの初期開発とマイクロサービス・BFF