Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
こんにちは、食べログシステム本部長の京和です。 本エントリでは Shopify の Engineering Blog から、Kirsten Westeinde による「Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity」を翻訳して掲載します。 食べログではユーザーや飲食店に価値を届けるスピードを最大化するべく、マイクロサービス化などをはじめとしたこれまでの組織やアーキテクチャを刷新するための取り組みを始めています。しかし、マイクロサービスはアプリケーションアーキテクチャとインフラアーキテクチャが複雑に絡み合ったシステムで技術的難易度が非常に高く、適切に構築できなければ「分散されたモノリス」と呼ばれるアンチパターンに陥ります。1 Shopifyではマイクロサービスではなく、
モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み 大規模なソフトウェア開発においてモノリシックかマイクロサービスかというアーキテクチャの議論がありますが、近年は第3の選択肢としてモジュラモノリスが話題になっています。いったんマイクロサービス化に舵を切りながら現在はモジュラモノリスに取り組むアソビューの考え方や進め方について、VPoEの兼平大資(disc99)さんによる寄稿です。 アソビューでは、現在の事業状況にマッチしていることや過去の経緯から、モジュラモノリスを中心としたアーキテクチャを採用しています。 今回は、なぜその選択をし、どのように実現しているかを紹介します。 記事の前半では、アソビューが提供する事業や、アーキテクチャに対する考え方、開発組織の歩みなどを説明します。 中盤以降は、アソビューにおけるモジュラモノリスへの取
私が働いているAniqueという会社では、1年前に全てのソフトウェアでTypescriptを採用することにしました。私たちが開発している進撃の巨人のNFTサービス “Attack on Titan: Legacy” でも採用しています。 TypescriptではNestJSという素晴らしいAPIフレームワークを利用することができ、生産性高く開発を続けることができます。また、私たちはフロントエンドでNext.jsを利用しています。言語レベルでのコンテキストスイッチを抑えることで、一人のエンジニアがフロントエンドとバックエンドのどちらもの機能を開発する環境が作れました。 しかし、Nodeならではの作法や設計について、Web上にはたくさんの情報があるものの、あまりにも情報が多すぎて、まとまったプラクティスになかなか出会うことができませんでした。そのため、最初はチーム内での共通認識を作るのに苦労し
こんにちは、プラットフォームチーム所属のまこたすです。 昨今、様々な場で「モジュラーモノリスを導入した」という話を目にするようになってきました。弊社でも昨年からモジュラーモノリスの試験導入を進めており、社内でノウハウが徐々に溜まってきたため、今回 技術ブログ で なぜ導入したのかと知見の共有 をさせていただけたらと思います。 想定読者 モノリスなアプリケーションの分割を検討している Railsへのモジュラーモノリスの導入を検討している 話さないこと チーム体制がどうあるべきかという観点の話 以下アーキテクチャについての詳細 モノリスアーキテクチャ モジュラーアーキテクチャ 背景 今回「モジュラーモノリスを導入した」というタイトルですが、最初に検討・導入に至るまでの背景について触れたいと思います。 hacomonoという組織・サービスの成長 hacomonoというサービスはリリースから現在に
非モジュラーモノリスからモジュラーモノリスへのステップ株式会社ナレッジワーク 川中さん なぜモジュラーモノリスにするのか?チーム事情 マイクロサービスと比較したメリット バージョン整理整合容易性 インフラ引用容易性 どのように変更したか?トップレベルには意味ごとにモジュールが並び、その中がclean architectureのようになっている モジュールが公開するAPI以外はinternal packageへ まずはディレクトリ分けまずmodule単位で切って全部公開(ディレクトリだけ移動する) 他のmoduleから内部データが無造作に使われていたりするため、隠蔽は諦める 言語によってはpackage公開ルール周りで不自然な構成になるので、諦める 一部モジュールAPIの公開(隠蔽していく)容易なモジュールから着手 最終構成発表資料より拝借LTの発表内容になかった追加事項モジュール間のRDB
こんなつぶやきをしたので、「モジュラーモノリス」について考える。特にモジュール性について考えてみる。 以下の主張は、実際のプロジェクト/プロダクトにとって最適かどうかは、具体的なビジネス要件、チームのスキルセット、運用上の制約など、多くの要因に依存する。アーキテクチャは常にトレードオフがあり、一つの解決策が全てのシナリオに適用できるわけではないので、その点を考慮して読んでほしい。 マイクロサービスではなくモジュラーモノリスを選択した場合には、しばしば以下の利点が強調される。 ネットワーク通信: モジュラーモノリスは、マイクロサービスと異なり、ネットワークを介した通信が発生しないため、ネットワーク遅延や断絶、通信エラーなどの問題が生じにくくなる データ整合性: 分散システムでは、データの整合性を保つために複雑なトランザクション管理やデータ同期が必要になるが、モジュラーモノリスでは同じデータベ
はじめに 最近機会があってモジュラモノリスについてあれこれぼんやり考えています。 その性質とかをかるく整理しつつ、モジュール境界としてgRPCをつかってみるアプローチについてあれこれ考えてみます。grpc-goについてのみ考えていて他の言語でどうなるかは考慮してないのであしからず ProtocolBuffersやgRPCは、IDLとそのコード生成を中心とした強力なエコシステムを持っており、そのメリットを享受しつつモジュラモノリスのモジュール境界として利用できんかな?という思考実験です。この構成は将来的にマイクロサービスにしたくなったときの抵抗も比較的穏やかなように思います。 そのままだと無駄にネットワークリクエストを垂れ流したりするので unix domain socketの利用 local function callへの置き換え の2つのアプローチを試してみようと思います。 これらはモジ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く