カテゴリー：マイクロサービス
-
【マイクロサービス】データベースの移行
07.18
DBを物理分割する。 メリット サーバーが物理的に分かれていると障害時の影響を下げることができます。 デメリット データベースのライセンス費用がサーバーごとにかかってしまいます。もし、SQLServer、Oracleなどライセンスが…
-
【マイクロサービス】アプリの移行
07.17
プロキシを活用する。 プロキシを挟んで古いサービスと、これから作成するマイクロサービスを振り分けるようにします。 メリット モノリスに対する修正を減らせる。 デメリット URL単位である程度機能として分割できている状態じゃないと使…
-
【マイクロサービス】「移行方法」
07.17
一気にモノリシックからマイクロサービスに移行するのではなく徐々に移行していくことが推奨されている。 向く事業 新規事業よりもドメイン境界がはっきりした成熟した事業にマイクロサービスは向く。 アセスメント 事業の目的や目標を明文化する…
-
マイクロサービスではたくさんサービスがあるのでどのサービスが問題になっているのかの障害発生箇所などが特定しずらいです。 複雑なシステムを横断的に監視できるようにするために三つのポイントがあります。 項目 説明 …
-
【マイクロサービス】「正常性確認」手法について
07.17
正常性確認用のAPIを作成する。 エンドポイントのURLは「/health」、「/hc」などにしておけば良いでしょう。 正常であればレスポンスに200を返し、異常であれば500を返すようにします。（リクエストボディの中には正常性情報…
-
【マイクロサービス】「サービスメッシュ」について
07.17
サービスメッシュとは？ サービスとは別に外付けとして実装します。なので言語や環境には依存しないです。 外付け機能の例 kubenetesにおける「サイドカー」などがあります。 代表的なサービスメッシュ lstio(Google、I…
-
【マイクロサービス】「リリース手法」の種類
07.17
リリース手法の種類 リリース方法 切り替え台数 ダウンタイム 一括リリース 全台 (デプロイ方法次第） カナリアリリース 一部 ほぼゼロ 一括リリース ユーザー全員にいきなり公開…
-
【マイクロサービス】「テスト」について
07.17
単体テスト 各サービス内のクラスのみで実施するテストです。（自動テスト） 課題 モックやスタブが大量に必要になってくる。 どうしても各サービスとの連携ができないのでモック化が増えます。基本的にはツールを利用して対応します。 …
-
【マイクロサービス】「データの結合」について
07.16
複数サービスにデータが散らばっているのでデータの結合についても考える必要がある。 API Composition ある一つのサービスが中心となってデータを収集、結合を行う方式です。 デメリット オーバーヘッドが高くなる。 …
-
普通にやればマイクロサービスはいろんなところにDBが乱立するのでデータ整合性が難しくなります。 2層コミット 分散データベースに対してそれぞれのDBにコミットしていき整合性を担保する古くからある手法です。 いきなりコミットするので…