JAWS UG 函館勉強会 Vol12 徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜
JAWS UG 函館勉強会 Vol12 徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜
The latest news from Google on open source releases, major projects, events, and student outreach programs. We are excited to introduce Service Weaver, an open source framework for building and deploying distributed applications. Service Weaver allows you to write your application as a modular monolith and deploy it as a set of microservices. More concretely, Service Weaver consists of two core pi
はじめに 用語の定義 取り組みの背景 マイクロサービス化の目的 モノリスのつらさ ふたたびマイクロサービス化の目的 マイクロサービスとは 採用技術について 技術スタック サービス構成 現状の課題 技術面 最後に はじめに こんにちは、マイクロサービス基盤チーム所属のzigeninです。 この記事では、マイクロサービス化の取り組みについて紹介します。 技術的な取り組みやチームに興味を持っていただければと思います。 用語の定義 はじめに本文で使用する単語を定義させていただきます。 コアドメイン:アンドパッドの事業に直結するドメイン 施工管理が該当します 施工管理は建設現場のマネジメントです。 ソフトウェア開発に例えるとプロジェクトマネジメントに近く、ツールとしてはJIRAやGitHub Projectをイメージしていただけると当たらずといえども遠からずです。 汎用ドメイン:コアドメインを支援す
2016年頃「サービスメッシュ」という用語は、マイクロサービス、クラウドコンピューティング、DevOpsの分野に登場しました。楽天的なあるチームは、2016年にこの用語を使用して彼らの製品である Linkerd を説明しました。コンピューティングの多くの概念と同様に、実際には、関連するパターンとテクノロジーの長い歴史があります。 サービスメッシュの登場は、主に IT ランドスケープの最悪の状況によるものでした。開発者は、複数言語 (ポリグロット) アプローチを使用して分散システムの構築を開始し、動的なサービスディスカバリーを必要としていました。運用は一時的なインフラストラクチャの使用を開始し、避けられない通信障害を適切に処理し、ネットワークポリシーを適用したいと考えていました。プラットフォームチームは、Kubernetes などのコンテナオーケストレーションシステムの採用を開始し、Envo
2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て
サービスメッシュとは なんのために?なにを解決する?: サービスメッシュは、大規模な組織でのマイクロサービスの適用によって顕在する開発・運用上の問題に対処するためのツールです: オブザーバビリティ: システム全体がネットワークをまたいでしまい複雑になり開発時のトラブルシューティング・運用時の障害解決までの時間が増加する問題 障害分離: 分散ネットワークでのベストプラクティスであるリトライやタイムアウト等の実装が必要な問題 セキュリティ: ネットワーク通信増加によるセキュリティリスクの増加。アプリケーション間の通信のアクセス管理の問題。 この3領域の問題に対処するために導入・利用されます。 ネットワーク通信に関わる問題への対処をアプリケーションから切り離してインフラ層で実装するため、プロダクト開発者はよりプロダクト開発に集中でき、またシステム全体で一貫性のある実装・設定を維持しやすいため運用
AWS Startup ブログ スタートアップのためのマイクロサービス入門 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 以前「スタートアップのためのコンテナ入門 – Kubernetes 編」を出した際に記事内で、マイクロサービスやサービスメッシュにふれる機会がありました。今回は AWS でデベロッパーアドボケイトをしているトリ氏 (@toricls) にマイクロサービスについて記事を寄稿いただきました。 ※ 本記事は Software Design 2020年7月号 に掲載された「スタートアップのためのAWSテクノロジー講座 – マイクロサービスのあるべき姿と特徴を知る」からの転載、改修版です。 目次 マイクロサービスにはコンテナが必要なのか? サービスメッシュは本当に必要なのか? 「マイクロサービス」という言葉の功罪 マイクロサービスが必
はじめに こんにちは。EC基盤本部SRE部プラットフォームSREの三神です。 2021年3月18日、ZOZOTOWNは大規模なリニューアルをしました。その中でも、コスメ専門モールのZOZOCOSMEと、ラグジュアリー&デザイナーズゾーンのZOZOVILLAを同時にオープンし、多くの反響をいただきました。 今回のリニューアルではBackends For Frontends(以下、BFF)にあたるZOZO Aggregation APIを構築しています。本記事ではZOZOTOWNが抱えていた課題とBFFアーキテクチャを採用した理由、またZOZO Aggregation API構築時に発生した課題と解決法についてご紹介します。 ZOZO Aggregation APIのサービスメッシュについてはこちらの記事でご紹介していますので合わせてご覧ください。 techblog.zozo.com BFFと
マイクロサービス・アーキテクチャ(MSA)を適用する際に頭を悩ます問題のひとつが「複数サービスにわたる更新操作」である。マイクロサービスを成すソフトウエアのまとまりは、個々に独自のデータストアを持っている。ゆえに複数サービスを横断する更新操作の際、トランザクション管理によるACID特性を保証できなくなる。 この問題に対処するために二相コミットや結果整合性等の考え方があるが、どのやり方でも限界があるし、ある種の制約や余分な手間を受け入れざるを得ない。もっとも穏当な設計方針は「複数サービスに渡る更新が起こるような粒度ではサービスを切り出さない」である。個々のサービスを実装する段になって悩む前に、サービス粒度の設計に関して事前に考慮すべきことがあるということだ。 前回記事で説明した「CRUD基準によるサブシステム分割」は、更新制御の面から見たサービス粒度の設計基準として応用できる。ドメイン駆動設
研修中に「マイクロサービス」の解説をしていると,たまに「モノリス分割」に関する質問が出てディスカッションをすることがある.当然ながら万能な分割アプローチはないけど,例えば DDD (Domain-driven design) などのアプローチを選択するなど,選択肢はいろいろある.そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ. 具体的には以下の「計8種類」のアプローチが紹介されている.原著を翻訳するのではなく,あくまで個人的なメモとしてまとめる.なお,日本語も個人的に載せているため,参考程度にしてもらればと! Warm Up with a Simple and Fairly Decoupled Capability(シンプルかつ分離された機能で準
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く