Couchbase Connect 15のセッション紹介シリーズ、第四弾、今日はINTUITのLead Developer、Application Architect、Umedさん、そしてCouchbaseのSolution Architect、Justinさんによる、TurboTax Online’s Journey into Microservices Architectureを紹介します。

TurboTax Online - 数百万のユーザが利用する20年の歴史を持つ、税金申告ソフトウェアは、モノリシックなアプリケーションからモダンなマイクロサービスベースのアーキテクチャへの道のりを歩んできました。このセッションでは、アーキテクチャ移行における課題、そしてその中でCouchbaseがどれだけ重要な役割を果たしたのかを紹介します。

マイクロサービスとは

モノリシックなアプローチでは、単一のアプリケーションとしてUI、ビジネスロジック、データアクセス、データ連携を処理。初期の開発は簡単だが、長期間運用すると問題が出てくる。(具体的にどういう問題がでるのかは、セッション後半で)

そこでマイクロサービスの登場。特定の、独立したサービスの提供にフォーカスした個別のサービス群でシステムを構築するアーキテクチャ戦略。

セッション中で紹介されていた、「The Art of Scalability」は、 テクノロジ、システムアーキテクチャのスケーラビリティだけでなく、チームや組織管理、ビジネスのスケーラビリティについても多くのページを使って記載されている本。eBay、 PayPalのアーキテクチャに関わってきたMartin Abott氏、Michael Fisher氏によって執筆されている。

この本の中で紹介されているスケーラビリティの指標が「スケールキューブ」。

スケールキューブ

X: システム/アプリケーションの冗長化、Y: サービスの分割でスケール、Z: データ分散によるスケール。

一つのアプリケーションインスタンスだけで負荷をさばけなくなると、同一のシステムを複数並べて負荷分散する (X軸)、これはよくアプリケーションサーバのスケールアウトで利用される軸だが、同一のデータベースインスタンスにアクセスしていると今度はそこがネックになるので、データを分割してスケールすることも必要になる (Z軸)。さらにこのような複雑なシステムを長期間運用し、成長させるためにはサービスを分割し管理しやすくすることも必要 (Y軸)。

トラベルサイトのアプリでスケールキューブを適用した例:

このようなシステムでCouchbase Serverは主にZ軸、データの分散で活躍する。

Couchbase Server単体で見ると、クラスタ構成でX軸にもスケール、ノードを追加することでメモリ、CPU、ストレージリソースがリニアにスケールする。 さらにCouchbase 4.0からはCouchbase Server内でもQuery, Index, Data Serviceを分割し、Y軸でのスケールも可能になる。

トラベルアプリケーションで多く採用されるマイクロサービスアーキテクチャ例

Couchbaseを利用しているトラベルアプリケーションは多くあり、それらのシステムアーキテクチャの例。 Couchbase Serverをデータサービスとして中心に、その周辺にマイクロサービスを開発。Couchbaseのさらに後ろにはメインフレームも存在。 ファイナンシャル、インベントリ管理システムでは以前としてRDBMSを利用しているケースが多い。 高いパフォーマンスを提供するため、参照リクエストはCouchbaseから、データ更新は直接メインフレームに。 Couchbase Serverを利用することで、データの分散をより効率的に管理できるようになり、より多くのサービスに対応できる。

INTUITのTurboTax Online概要

INTUITでは2つのマーケットセグメントを扱っている:

• コンシューマ向けファイナンスソフトウェア、TurboTax、税金管理
• スモールビジネス、QuickBooks、会計管理パッケージ

TurboTax Onlineは20年もの歴史を持っている。 オンラインで税金の処理をすることが普及してくるにつれて、ユーザ数が拡大。 数百万の顧客へのサービスで、15億ドルのビジネスに成長。 ピーク時には25万の同時接続ユーザ、平均35分のセッション。 モノリシックなレガシーシステムは、Apache Web Server, Tomcat + Spring, TaxロジックEngine (C++), Oracle SQL, 外部サービス連携で構成されていた。

マイクロサービスでイノベーションを活性化!

モノリシックなアーキテクチャのせいで、イノベーションのペースがスローダウンしてしまっていた。 すべての変更は完全なビルド、リグレッションテストが必要 -> リリースに時間がかかる -> A/Bテストが難しい、フィードバックを活かして次のイテレーションを開発、という流れが作れない。

ドメインを分割し、シンプルなAPIでサービスとして隠蔽、小さな多数のサービスに分割し、開発からリリースまでのイテレーションが柔軟に。 マイクロサービス化はイノベーションの活性化が主な動機。

マイクロサービス化したシステムのアーキテクチャでは、様々なデータをRDBに格納するのは大変だったので、画像データなどのファイルはGlusterに、メタデータをCassandraに保存している。

システムがこの形になってからすでに3年程度運用されている。

マイクロサービスへ変更後に発生した課題

一つの課題を解決すると、別の課題が発生するのがテクノロジ、ビジネスの常。

サービス間通信のオーバヘッド、複数のサービスが同一のデータ数ミリ秒内で参照する、データストアが迅速にスケールできない、外部サービスへのアクセス、end-to-endのユーザエクスペリエンスの管理。

2015年で2014年の会計処理を行う場合、2014年のデータはすでに発生しているもので変更されることがほとんど無い。

セッションストアとしてもCassandraを利用していたが、GCなどの問題であまりハッピーではなかった。パラメータのチューニングが非常に辛かった。

キャッシュを導入することに。 書き込みが頻繁に発生する場合は、キャッシュ層に書き込み、定期的にバックエンドのストレージへフラッシュ。税金の申告時にはユーザは同一のデータを長時間に渡って編集する。セッションデータに編集中のドキュメントがそのまま入っていて、それをキャッシュ層に保存している。

キャッシュサービスのREST APIのバックにCouchbaseクラスタを導入。 Cassandra + Glusterのバックエンドの手前にキャッシュサービスを追加。

キャッシュの導入効果

• readレスポンスタイム: 50%短縮!
• writeレスポンスタイム: 1/4に短縮!
• サービス間連携トラフィック: 20%削減!

なぜCouchbase Serverを選んだのか?

• インメモリのKVS: サイジングをしっかりして、全てがRAMに載るようにした
• Java SDKが簡単に利用できる
• XDCRをサポートしている、デプロイが簡単
• AppDynamicsやSplunkなどの既存モニタリングツールとの連携が容易

AppDynamicsやSplunkとの連携ができても、運用チームはCouchbase管理コンソールが便利なのでそっちを見ることも多い。

多くのチームで、今後、Couchbaseの利用用途を広げていきたいと感じている:

• サービスプラットフォームの主要部分での利用
• データマイニング、データ分析
• Write-behindキャッシュ
• Memcached, Ehcacheのリプレイス

QA

• Couchbaseのデータサイズ: 数百万のTaxドキュメント(400 - 500KB)
• Couchbase Server 2.5を利用
• 暗号化は? データセンタ内のセンシティブなゾーンに配置している、オーバヘッドを避けるため暗号化はしていない
• キャッシュなのでTTLを利用、2-4時間、税金の申告のユースケースにあってる TTLの延命にはtouchを利用
• TTLが切れるドキュメントを取得したいならTTLを利用したViewを使うこともできる、couchbaselabsのexpiry-notifierを参照
• モノリシックなシステムからマイクロサービスへの移行は段階的に行っている、まだ以前のシステムも並行して稼働中
• Cassandraもキャッシュがあるが? 古いバージョンを使っている、それにGCの問題がある
• SpringのCache Abstractionを使ってる? 使ってない、キャッシュ層もサービスとして開発していて、利用する側からサービス呼び出しを行っている

まとめ

INTUITのTurboTaxでの利用事例や、トラベルアプリケーションでの利用事例のように、他のデータストアを利用していても、高性能なキャッシュとしてCouchbase Serverを導入している事例が数多くあります。 メインのデータストアを移行するとなると、かなり大変な作業になりますが、 既存システムの課題を解決するために、まずはキャッシュとしてCouchbase Serverの利用を開始するのは短期間で大きな成果が出るので良いですね!