マイクロサービス移行を阻むレガシーとの戦い方特集:マイクロサービス入門(6)(2/2 ページ)

» 2020年03月03日 05時00分 公開
[川上徹オイシックス・ラ・大地]
前のページへ 1|2       

マイクロサービスアーキテクチャベースの開発における課題

 Oisixでは、マイクロサービスのプラットフォームとしてkubernetesを採用している。

 kubernetes上に構築したRESTful APIを既存システムから呼び出すことで機能を段階的に移行していくというのが基本的なアプローチだ。その上で発生した課題を2点紹介する。

kubernetesのバージョンアップに関する課題

 kubernetesはリリースのサイクルも早く、バージョンアップをするためのツールやコマンドも提供されているが、バージョンアップをしていいかどうかという点に関しては注意が必要だ。

 コマンドによるバージョンアップが必ず成功するとは限らない上、失敗した場合にリカバリー可能であるかは未知数だからだ。アップデートに成功した場合でもマネージドkubernetesサービスを用いてマルチリージョン構成にしている場合を除き、一定のダウンタイムも発生してしまうだろう。

 Oisixの開発においても、バージョンアップ操作ではないが、あるプロダクトのエージェントをkubernetesクラスタから削除しようとした際にクラスタを破壊してしまったことがある。稼働中のkubernetesクラスタに対しての直接の変更操作は相応のリスクを伴うものと考えるべきだろう。

 kubernetesに対してアプリケーションをリリースする場合は、Manifestと呼ばれるYAMLファイルを適用する必要がある。kubernetesをバージョンアップさせることでそのYAMLファイルがバージョンアップ前と同様の動作をするとは限らない。廃止、あるいは振る舞いの変わっている設定も存在する可能性がある。

 そのため、kubernetesのバージョンアップは稼働中のクラスタに対するアップデートではなく、新規にkubernetesクラスタを構築し、リクエストを振り分けることで切り替えることを推奨したい。そしてそれが可能な構成にしておくことが望ましい。

ルーティングによるKubernetesクラスタの移行 ルーティングによるKubernetesクラスタの移行

 Oisixでは、kubernetesクラスタに対するリクエストをマネージドのAPI Gatewayサービスを経由したものに一元化し、API Gatewayサービスに設定したバックエンドサービスのURL(kubernetesクラスタ内のIngressリソースにひも付けたURL)をもとにリクエストをルーティングさせる方式を採用した。

 これにより、新規に立ち上げたkubernetesクラスタに対するルーティングをAPI単位に制御し、段階的な移行や切り戻しが可能になっている。

Feature Toggleの活用

 kubernetesをプラットフォームとした場合のリリースはDeploymentの設定によるローリングアップデートやIstioのTraffic Shiftingによるカナリアリリースなど、安全にリリースするための仕組みが存在する。

 しかしOisixにおけるリリースでは、特定のユーザーのみに対する実験的な機能の提供や、IstioのTraffic Shiftingのような割合ベースの制御よりも細かい単位でのカナリアリリースを行うという要件があった。

 そのため「Feature Toggle」(「Feature Flag」や「Feature Switch」と呼ばれることもある)の仕組みを導入した。これは設定状況を確認できるAPIを構築し、そのAPIの情報を基に機能の有効/無効を切り替えられるものだ。これにより、リリース状況を一元管理できる。

 各機能が有効となる条件をDBに保持し、Feature Toggle APIを通じて取得可能とした。APIの呼び出し元は取得した条件をもとに判定を行い、既存の業務ロジックを実行するか、新規のAPIを呼び出すかを判定する。DBの管理はマイグレーションツールを用いてFeature Toggle APIのGitリポジトリ上にあるSQLを反映することで行う方針としている。また、取得した判定条件は一定期間のキャッシュを保持させるよう実装し、Webサーバへの負荷も配慮した。

Feature Toggleを用いた機能の変更 Feature Toggleを用いた機能の変更

 今回はOisixをマイクロサービスアーキテクチャに移行する上で生まれた課題と、それにどう立ち向かったのかを解説した。システム開発において向き合うべき課題はシステムによって千差万別ではあると思うが、何かの参考になれば幸いだ。

 次回は、マイクロサービスアーキテクチャに移行させた後の開発、運用はどうなるのか、どうしているのかを紹介する。

筆者紹介

川上徹

金融系のSIerを経て2018年にオイシックス・ラ・大地入社。ECサイトOisixのマイクロサービス化に向けた開発プロセスの整備を実施。好きなプログラミング言語はKotlin。趣味は住宅ローンの繰り上げ返済。野菜よりはお肉が好き。

Oisix ra daichi エンジニアブログ

勉強会やイベントレポートを中心に更新中!


特集:マイクロサービス入門 「2025年の崖」を乗り越えるためのシステム開発の姿

複雑化、老朽化、ブラックボックス化した既存システムの残存で、2025年以降に予想される経済損失は最大12兆円/年といわれている。これを経済産業省は「2025年の崖」と呼び、企業に警鐘を鳴らす「DXレポート」を公開した。レポートでは、システム開発に取り入れるべきアーキテクチャとして「マイクロサービス」を挙げている。本特集では、マイクロサービスとは何か、システムをマイクロサービスにさせるとどのような課題が生まれるのか、モノリシックなサービスをマイクロサービスに移行させた事例などを通じて、どの場面でマイクロサービスを活用すべきか、現実解を探る。



前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

4AI by @IT - AIを作り、動かし、守り、生かす
Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。