マイクロサービスアーキテクチャへの移行を進める上で生まれた課題にどう取り組んだのか。オイシックス・ラ・大地の川上徹氏がOisixのマイクロサービス移行のハードルにどう取り組んだのか紹介します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
Oisixは2000年の創業以来、一度も全面的なシステムリプレースを行わず、システムの改修を続けてきたECサイトだ。マイクロサービスアーキテクチャへの転換を検討し始めた2017年時点で、17年以上も創業当時のアーキテクチャのまま、運用を続けてきたというわけだ。
今回はそのOisixをマイクロサービスアーキテクチャに移行する上で生まれた課題にどう立ち向かったのかを解説する。
システムアーキテクチャを刷新する上で、まず最優先に取り組むべきなのはそのシステムが構成する業務の分析/再定義になるだろう。
システムの現状分析を基に、開発、運用のプロセスあるいはサービス提供をする上でのボトルネックは何かを見極め、それを解消するためのアプローチを探る必要がある。これは通常のシステムリプレースであっても、マイクロサービスアーキテクチャへの移行であっても変わらない。
しかし、システムの現状を分析するといっても、長期間にわたって運用、改修を続けてきたシステムのアプリケーションやデータベース(DB)の構成は複雑化し、難解なものになっていることは容易に想像が付く。現在の業務プロセスやサービスの仕様が構築されたいきさつを知る担当者も異動や離職などで現場を離れているケースも少なくないはずだ。
Oisixでもそれは例外ではなかった。改修の積み重ねによるアプリケーションコードの難解さはもとより、過去の施策において実験的に導入したサービスのためのコードや一時的な作業データがDBに残っているなど、分析は困難を極めていたのだ。
Oisixのマイクロサービスアーキテクチャ移行に当たっては、まずアプリケーションに対して稼働状況を分析し、モノリシックなアプリケーションの中で実行頻度の高い機能はどれか、あるいは実行されていない機能はどれかを分析する必要があった。
そこで、稼働中のアプリケーションの基本機能部分に対して実行時にログを出力させる実装を行い、その結果を分析できる仕組みを構築した。
稼働中のアプリケーションの動作に性能面で影響を与えないようにするため、非同期にログを出力する実装とし、出力先は各アプリケーションサーバに配置したオープンソースのデータコレクターである「fluentd」を指定した。
fluentdに出力したログは同様にオープンソースのデータ検索/分析エンジンである「Elasticsearch」に集約し、「Kibana」で可視化する方針とした。
この仕組みを用いて、実行頻度の高い機能に対して優先的に移行を行い、その後細部の機能にもログを出力する設定を行って、不要な機能の取捨選択をするアプローチを採用した。
既存のシステム構成において最も問題視されていたのが、アプリケーションがステートフルであることによりアプリケーションサーバのスケールを阻害していたことだ。
アプリケーションが持つステートの例としては、以下のようなものがある。
Oisixで課題になったのはHTTPセッションだ。
OisixはJavaによるServletベースのWebアプリケーションであり、画面表示にはJSP(JavaServer Pages)を用いているが、HTTPセッションへのアクセスに関しては明確なルールを定めずに行ってきたといういきさつがある。
そのため実態は、JSPを含むアプリケーションの各所でハードコードされたセッションキーによるアクセスや、SerializableでないオブジェクトのHTTPセッションへの格納も行われていた。
特に後者のSerializableでないオブジェクトのHTTPセッションへの格納は、アプリケーション稼働状況の分析を目的に構築したElasticsearchへのログ集約の仕組みを流用し、HTTPセッションへオブジェクトを格納する際にSerializeを行い、エラーとなったオブジェクトの情報をElasticsearchへ送信することで、該当するオブジェクトの情報を収集した。
その上で、以下の2つのアプローチで既存アプリケーションのステートレス化を目指した。
Copyright © ITmedia, Inc. All Rights Reserved.