【ZOZOTOWNマイクロサービス化】API Gatewayを自社開発したノウハウ大公開！ - ZOZO TECH BLOG
はじめに こんにちは。ECプラットフォーム部のAPI基盤チームに所属している籏野 @gold_kou と申します。普段は、GoでAPI GatewayやID基盤（認証マイクロサービス）の開発をしています。 ZOZOテクノロジーズでは、2020年11月5日にZOZO Technologies Meetup〜ZOZOTOWNシステムリプレイスの裏側〜を開催しました。その中で発表されたAPI Gatewayによるマイクロサービスへのアクセス制御に関して、当日話せなかった内容も含めて、API Gatewayについてこの記事で網羅的にまとめました。 API Gatewayやマイクロサービスに興味ある方、「API Gateway」という言葉は知っているけど中身はよく分からないという方向けの記事なので、読んでいただけると幸いです。 はじめに ZOZOTOWNのリプレイス マイクロサービス化の目的 ストラ
マイクロサービスでチームを分離したくないマン - まっちゅーのチラ裏
コンウェイの法則とかで、マイクロサービス=組織 という話になることが多いなと感じる。 正解の場合もあるし、不正解の場合もあると思っていて、個人的には小さいチームでもマイクロサービスをやるメリットは技術的にも組織的にもあると思う。 そのメリットを無視してすぐ組織の話に持っていきたくないので、基本分離したくないマンとしての主張を書いておく 技術観点でのメリット いまさら語るまでもないけど、 ドメイン境界の分離 デプロイ独立性 リソースの最適配分 障害の局所化(サーキットブレーカー等) このうち、ドメイン境界の分離だけはモジュラモノリスで対応可能だが、あとの3つにはマイクロサービスが必須。(もっとあるかも) この3つが必要なのにモノリス or モジュラモノリス で進める判断をするということはシステムの表現力を落とすことに直結する。 もちろん、複雑度は増すし難易度も増す。熟練のサーバーサイドエンジ
Microservices分割大全 - kawasima
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 Microservices Platformの進捗（2019年） | メルカリエンジニアリング
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として最低限の機能を整備したにすぎず，さ
Monolith によるモダンアーキテクチャの再考 / Rethink modern architectures with Monolith
Cloud Native Meetup Tokyo #11 「Monolith によるモダンアーキテクチャの再考」のスライド資料です
1年間のシステム運用を通して分かったIstioの嬉しさと活用における注意点 / Benefits and Usage Notes of Istio
English ver CloudNative Days Kansai 2019 #CNDK2019 日々複雑化するマイクロサービスを運用するにあたり，サービスメッシュ実装のIstioが注目を集めています。しかし，Istioの話題性・機能性とは裏腹に，仕様の複雑さやプラクティスの無さのため，実サービスへのIstio導入は依然として敷居が高いです。日立製作所では社内開発環境の提供のため，2000+PodのKubernetesクラスタにて1年に渡りIstioを使ったマイクロサービスの運用に取り組んできました。本講演ではこの運用を通して得たIstio利用時の問題やその対策といったプラクティスを紹介します。
Shopifyはいかにしてモジュラモノリスへ移行したか
原文(投稿日：2019/07/29)へのリンク ShopifyのシニアエンジニアであるKirsten Westeinde氏がShopify Unite 2019で、Shopifyにおけるモジュラモノリス(modular monolith)への展開について論じた。変更をいつ行うか、どのように達成するか、といった判断にデザインペイオフラインを使用したこと、ターゲットアーキテクチャからマイクロサービスを除外した理由、などがその内容だ。 重要な点は、モノリスは必ずしも悪いアーキテクチャではなく、単一のテストおよび展開パイプラインなど多くのメリットがある、ということだ。新たな機能を短期間で提供する必要のあるプロジェクトを立ち上げるには、これは非常に有用だ。アーキテクチャの改善に着手すべきなのは、"設計のペイオフライン"を越えた時、すなわち設計の悪さが機能開発を妨げるポイントにおいてのみである。Sho
Dapr - Distributed Application Runtime
The Distributed Application Runtime (Dapr) provides APIs that simplify microservice connectivity. Whether your communication pattern is service to service invocation or pub/sub messaging, Dapr helps you write resilient and secured microservices. By letting Dapr’s sidecar take care of the complex challenges such as service discovery, message broker integration, encryption, observability, and secret
クラウドネイティブとKubernetes（だいたいあってるクラウドネイティブ）
社内のウェビナーで使用した資料をほぼそのまま掲載しました。 クラウドネイティブをふわっとわかったつもりになる、考え方の入り口を見つけることを補助するための初心者向け資料です。 具体的な技術は一切解説しませんし、「良い」評価と「悪い」評価も真っ二つだったので人を選ぶ資料であることを先に述べておきます。
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
マイクロサービスにおける 最高のDXを目指して / Microservices vs DX
https://cloudnativedays.jp/cndt2019/ での登壇資料です
メルペイのマイクロサービスの構築と運用 / CloudNative Days Tokyo2019
メルペイのマイクロサービスの構築と運用 2019.07.22 に CloudNative Days Tokyo2019 で発表した内容です。 なぜメルペイがマイクロサービスアーキテクチャを選択したか、メルペイのマイクロサービスの構築と運用をどのように行ったか、などを話しました。
開発者向けの基盤をつくる
ハッカーズチャンプルー2019（ http://hackers-champloo.org/2019 ）の発表資料です
Web Developer も知っておきたい Kubernetes における Sidecar Pattern と Ambassador Pattern - スタディサプリ Product Team Blog
Site Reliability Engineering チームの @yuya-takeyama です。 年末年始頃は React Native でのアプリ開発をやっていた気がしますが、「スキルを Web 開発から SRE の領域まで広げたい」という以前からの私自身の思いと、「Kubernetes による Microservices 基盤を作っていくメンバーがもっと必要」「Microservices を技術面だけでなく組織面でも Production Ready な形でやっていく上で Developer と SRE のつなぎ役が必要」という会社の状況が一致したので、異動して AWS, Kubernetes または MongoDB などと向き合っています。 3 行でまとめ Sidecar Pattern はアプリケーションのコンテナから再利用可能な部分をもう一つのコンテナとして切り出すパター
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - message-db/message-db: Microservice native message and event store for Postgres
メルペイのマイクロサービスとCloud Native / CloudNative Days Kansai2019
ウォレットアプリKyashの先 〜 Kyash Directのアーキテクチャ
理想的なマイクロサービスアーキテクチャを目指す継続的改善 / Re-architecturing of Microservices #CNDT2019
マイクロサービスの成果を可視化する - Cloud Function in Go at Mercari - Speaker Deck
マイクロサービスにおける技術と組織の衝突に向き合う / Manage the Conflict between Microservices Architecture and Organization Structure
