JTBのIT企画担当が語る クラウド移行「オンプレ接続問題」解決の鍵：オンプレミスとAWSの「粗結合」パッケージ

国内大手の旅行会社であるJTBは、プライベートクラウド「J-Cloud」で運用してきたアンケートシステムを、パートナーである情報基盤開発の助けを得ながらAmazon Web Services（AWS）に移行した。その狙いと、移行にまつわるポイントを尋ねた。

[PR／ITmedia]

PR

デジタル化推進の中で最適な基盤を模索し、パブリッククラウドに着目

JTB　白水友明氏

　国内旅行業界大手のJTBは100年を超える歴史を持つ。ネット専業の旅行会社をはじめ、ITを駆使する新興企業の出現で旅行業界が激変する中、同社も安穏とせずデジタル化を促進している。

　「デジタル技術やデータを活用し、JTBの強みを生かせるブランド価値の創造、顧客体験価値の向上、市場環境の変化へのスピーディーな対応を実現したいと考えています」と話すのは、JTBの白水友明氏（個人事業本部　事業統括部　IT企画担当マネージャー　デジタル化推進プロジェクト担当）だ。

　JTBはシステム基盤にその時々の技術トレンドを取り入れ、最善の形を模索してきた。仮想化技術を活用した高性能プライベートクラウド「J-Cloud」もその一つで、多数の旅行販売システムや周辺システムが安定稼働する。

　だがテクノロジーや外部環境は変化する。構築から数年が経過し、性能面での投資パフォーマンスの比較優位性が失われ、プライベートクラウド基盤で利用していたソフトウェアのライセンス体系が大幅に変更された。新たな移行先の模索が必要だった。

　「グループ各社のコストを抑えるため、J-Cloudへの集約を促進し、グループ各社が個別に構築するコストと比較して、一定の削減効果を出してきました。一方、今後のシステムやサーバの増加、ハードウェア障害時のデータ保全対策、セキュリティ対策、BCP対策などのシステム基盤強化や、ハードウェアとソフトウェアの保守切れに伴う投資を想定すると、パブリッククラウド利用の方が安価でした。またPaaS（Platform as a Service）が、OSや一部ミドルウェアの自動アップグレードができたり、迅速なサーバ利用や自動リソース追加ができたりと機能が充実していることから、パブリッククラウドに舵を切りました」（白水氏）

　JTBは推奨のパブリッククラウドとして「Amazon Web Services」（以下、AWS）と「Microsoft Azure」を掲げ、そのいずれかへの移行を進めている。今回のアンケートシステムのケースでは、既存のアプリケーションやデータベースへの変更が小さく、最もコストパフォーマンスに優れていたことからAWSを採用することを決定した。

期限が迫る中、旅行販売システムと連動するアンケートシステムをAWSに移行

　JTBはお客さまから、接客や商品内容の充実度、宿泊施設の評価など、幅広いサービス内容についてスマートフォン、Webサイト、紙といったメディアを問わずに収集する。同社は顧客推奨意向（NPS）を経営戦略上の最重要指標の一つとしており、アンケートシステムは重要な役割を担う。結果は、社員や店舗の評価に活用される他、宿泊施設の評価にも反映される。

　システムは、朝8時から夜11時までの業務Webアプリケーションとして年間稼働率99.9％の運用が求められる。お客さまごとの旅行内容にカスタマイズしたアンケート用紙を接客中に印刷して渡す業務をサポートするからだ。

　店舗担当者は、来店したお客さまが過去にアンケートでどのような評価をしたかを参考にしつつ、旅行プランを提案する。これを実現するには、販売系の旅行販売システムと連動しつつ、蓄積されたアンケート回答と売り上げ情報をひも付け、最大約2000万行に上るレコードから高速で検索、集計できることが必須だった。

　パブリッククラウドへの移行方針が定まったのは2018年10月で、移行完了期限はJ-Cloudのハードウェア保守期限である2019年3月末日を基準に設定された。約半年という短期間で要件定義から予算立案、設計実装までを完了する必要があった。また要件として旅行販売システムなどの複数システムとの連携維持が必須だった。

　しかし移行調査を進めるに従って、連携に利用される冗長化通信方式の違いで、連携システムを巻き込んだ大改修となってしまう可能性が浮上してきた。

パッケージ導入と柔軟なリスクマネジメントで、数々のハードルをクリア

　このような状況に対し、以前からJTBのシステム開発を支援してきた情報基盤開発は「Service Broker VPC」パッケージを利用したAWS移行プランを提案した。

　システムの可用性を確保するにはシングルポイントを避ける冗長設計が基本だ。ハードウェアやソフトウェアの偶発的なトラブル、緊急メンテナンスによる影響を避けるには通信を含むサーバ系全体を冗長化させるのが好ましい。

　他のシステムとの連携について調査を行うと、ファイアウォールやセキュリティアプライアンスなどを置換、改修せずに冗長化通信を保持するには、AWS側にも固定IPアドレス通信が必須との結論が得られた。

　しかし、AWSはDNSホスト名による変動IPアドレス通信に依拠した拡張性、冗長性確保が主流だ。変動IPアドレス通信はオンプレミス側にとって適合性が低く、逆にオンプレミス環境の固定IPアドレス通信をAWSに安直に持ち込んでしまうとその良さが消え、不安定で拡張性の低いクラウド環境が残る。

　そこで情報基盤開発は「逆転の発想」を取った。手堅い動作が求められるオンプレミスのシステムには、固定IP接続による通信機能に特化させた仮想ネットワーク環境（VPC）を対向させる。サービス側VPCは変動IP接続による通信を前提として、アンケートシステムがAWSの機能をフル活用してどんどん変化し、最適化していくことを妨げない。

　通信方式が異なる2つのVPCの中間ポイントに、固定IP通信と変動IP通信間の変換エンジンであるService Broker VPCを技術的コアとして設け、通信冗長性を保ったまま結合する。双方の良さを生かしながら相互の影響排除を達成する、オンプレミスとAWS間の「粗結合」アーキテクチャだ。

　ほとんどの連携システムを改修せずに移行する計画ができたが、現実は厳しかった。回線品質やセキュリティの観点から専用線通信は必須だが、短納期故に稼働がプロジェクトの終盤となった。ルーティングのテストや調整期間が短く、調整漏れにより連携システムからの通信が新システム側に到達できなくなるというインフラ側のリスクが顕在化したのだ。

　そこで情報基盤開発は、旅行販売システムとの連携の役割を果たす機能を暫定的にオンプレミス側に残し、現状の通信経路を最大限に用いて、オンプレミスとパブリッククラウドを媒介接続できるフェイルセーフ移行プランを提示した。

　これにより連携システム側の通信上の課題の解消を待たずに、連携機能を保持した上で新システムを稼働できた。課題の解消後に直結通信に切り替え、リスクのないスムーズな移行を実現した。

拡張性とセキュリティを高いレベルで両立

　本移行では、販売システムとの連携を考慮して、もともと高い基準を満たしていたセキュリティ品質の維持が必須とされた。そこでAWSの各種セキュリティサービスのみならず、Service Broker VPCパッケージ付属の共通化、集中化されたカスタム対策を活用し、セキュリティ品質を向上した。

　セキュリティ対策ソフトの更新やソフトウェアパッチを提供する更新サーバが付属し、万が一、サービスサーバがマルウェアに感染しても未知のホストにデータ送信できない閉鎖ネットワーク設計を無理なく実現できた。

　多くの業界がセキュリティ標準として定める「CISセキュリティベンチマーク」をクリアするテンプレートがサーバOSの基盤として活用された。AWSアカウントに対するシングルサインオンのルールが整理されて危険なパスワード運用がなくなり、ロールベースアクセス制御（RBAC）の徹底と開発者の効率向上が両立した。

　その他、管理者操作ログや監査ログ、アクセスログなどの収集検索機能、エスカレーション付きの自動監視機能が付属されたため、管理の行き届いたサーバ運用を実現できる。またAWSマルチアカウント統合環境により、権限や会計を分離しながら最大2500サービス分のVPCを接続でき、ベストプラクティスに沿った拡張性を享受可能だ。さらにInfrastructure as Codeツールの導入により、設定ミスの排除やテストの自動化が実現でき、高いインテグリティを短納期で達成する。

　白水氏は「拡張性やセキュリティといった技術的な観点を踏まえた高いレベルの提案で、私だけでなくIT部門の他のメンバーも堅実なプランだと結論付けました。プロジェクト計画もしっかりしたレベルで『短期間でも、これで行けるな』と安心感がありました」と評価する。

Service Broker VPCのシステム構成イメージ（出典：情報基盤開発）

　移行プロジェクトが動き出してからのプロジェクトマネジメントも満足だと言う。「JTBグループの情報システム会社であるJTB情報システムをはじめ、さまざまな関係者と調整し、関連システムやネットワークと連携する必要がありましたが、しっかり束ねていただきました。月1回の定例会議で確実に進捗（しんちょく）が報告され、課題があればすぐに具体的な解決策が示されました。最終的に計画よりも2〜3週間前倒しでシステムを稼働できました」（白水氏）

　さらに同氏は「最初は堅そうな会社という印象でしたが、実際はフットワークがとても軽く、ちょっと困ったことでも解決を優先してすぐに来てもらえたので非常に助かりました。社内への提案フェーズでも『経営陣の承認を得るために、こういう情報がほしい』といった要請に対して、迅速な情報提供の支援を得られました」と振り返る。

導入パッケージのメソッドは他のシステム移行へ波及、デジタル化を加速

　アンケートシステムの移行は2019年4月に完了した。本稼働から現在までの運用は順調だ。2019年8月に東京リージョンの一部で数時間にわたる大規模障害が発生したが、想定通りAWS側のフェイルオーバーのみで短時間に全機能が自動回復し、冗長設計の正しさが実地検証された。

　情報基盤開発は、移行提案に盛り込んだ設計の考え方、設計図、ノウハウをJTBと共有した。JTBはこれらの情報が今後の取り組みにも生かせると感じている。

　「JTBにとってどういう製品やクラウドサービスが最適なのか、どのように移行するのがいいのか、技術動向や他社の動きなども踏まえつつ、AWSに関する知見や技術力を持つ情報基盤開発さんには今後もパートナーとしてお付き合いいただきたいと期待しています」（白水氏）