サントリーグループは約20年間にわたって使ってきた基幹システムからAWSに移行した。同社がシステム全体のマイクロサービス化を実施した狙いはどこにあるのか。
この記事は会員限定です。会員登録すると全てご覧いただけます。
ビジネスの根幹を担う基幹システムにおいて、サントリーグループが選んだのはフルスクラッチのJavaアプリケーションと、システム全体のマイクロサービス化、オープンなデータ基盤だった。その狙いはどこにあるのか、システム構成の詳細とは。
本稿は、Amazon Web Service(AWS)が主催したイベント「AWS Summit Japan 2025」(開催日:2025年6月25〜26日)でサントリーホールディングスの齋藤 陽氏(デジタル本部 情報システム部部長)と石橋浩平氏(デジタル本部 情報システム部)が「市場変化に対応するサントリーグループの基幹システム改革〜SaaS・クラウドネイティブ・AWSマネージドサービス活用の最前線〜」というテーマで講演した内容を編集部で再構成したものだ。
サントリーは酒類をはじめとする飲料や食品、健康関連事業などをグローバルで展開している。2024年度の売上高は約3兆円(うち日本国内が占める割合は約48%)、グループ会社265社、グループ従業員約4万人を擁する。
サントリーグループのDX(デジタルトランスフォーメーション)の代表的な取り組みの一つが「サントリー天然水北アルプス信濃の森工場」(長野県大町市)だ。同工場はデジタル技術を活用したスマートファクトリー化を進めており、品質管理におけるトレーサビリティの向上や製造機器のデータを生かしたオペレーション効率化に取り組んでいる。
同社のIT環境の特徴は、約500種類のSaaSやパッケージ製品を利用する一方で、基幹システムにおいてはパッケージ型のERPは使わず、Javaでスクラッチ開発した独自アプリケーションを採用する点にある。
クラウドリフトに当たって新規で開発するシステムは「AWSを使い倒す」をコンセプトに、AWSのさまざまなサービスを可能な限り活用する形で進められた。現在同社で稼働しているのは「Amazon ECS」(Elastic Container Service)によるコンテナ管理サービスが約180、サーバレスコンピューティングサービスの「AWS Lambda」が約3500、APIサービスが約400などだ。
AWS移行の実務を指揮したサントリーホールディングスの石橋浩平氏(デジタル本部 情報システム部)によれば、従来のシステムの特徴は次の通りだ。
従来の基幹システムは、生産や営業、自販機などの業務ドメインごとに異なる構成のシステムを個別に運用しており、ドメインごとのシステム運用や改修が困難で機動力にかける点が問題だった。この問題を解決するため、現在の基幹システムでは各アプリケーションを1つのドメインに統合し、共通機能を約400のJavaコンポーネントに集約している。
機能の標準化と共通化を進めるに当たり、当初はドメイン間のデータ参照はレプリケートしたデータを参照する仕組みを採っていた。だがこの構成では、データ取得と参照にタイムラグが生じるなど、事業を推進する上で障壁になる要素も残っていた。
石橋氏は基幹システムが抱えていたその他の問題点について次のように整理した。
「(AWS移行をきっかけとした)システム刷新でこれらの課題を解決しようとしています」(石橋氏)
サントリーグループは、まず業務ドメインごとに集約しているアプリケーションの運用を見直している。
「例えば営業ドメインだけで40〜50のアプリケーションが動いています。新しいミドルウェアの機能を使いたいのでバージョンアップしようとしても、これらをまとめて動かさなければいけないため、対応が遅れています。そこでこの環境をコンテナ化して、ミドルウェアを切り離すことでアプリケーションの運用負荷を軽くして、最新技術の提供をしやすくしています」(石橋氏)
従来の基幹システムは、各ドメインでモノリシックに作られており、1つのアプリケーションに複数機能が搭載されている。各機能が密接に結合しているために改修したい機能を変えようとしたときに、変えたくない別の機能にも影響が及ぶ恐れがあり、機能変更がなかなか進まない状態だった。画面遷移のシナリオ検討も煩雑になっていた。
それをシングルページアプリケーション(SPA)の考え方にならってバックエンドではサービスを分割しながら、フロントエンドはシステムに影響を与えずに柔軟に改変できるように変更する計画だ。
「当初、AWS Lambdaを検討しましたが、起動遅延の問題からレスポンスが安定しませんでしたが、アプリケーションをコンテナ化したことで、ある程度安定させられました。ただ、それでも私たちが求めるレスポンス要件(各APIのレスポンスが200ミリ秒以内)を満たしていませんでした。この問題はデータベースの前にキャッシュサーバを加えることで解決できました」(石橋氏)
さらに早いレスポンスが求められる業務には内部ルーティングに切り替えて、応答時間を40ミリ秒まで短縮することに成功している。これらの対策によって同社基幹システムはSPA構成を採りながら、基幹システムに求められるレスポンスの早さを実現している。
現在、石橋氏が所属する情報システム部は、基幹システムの改修と併せてAWSの機能を生かした夜間バッチ処理削減も進めている。21時にシステムを閉じ、再びシステムを開ける翌朝6時までの間にこれらの処理を全て完了させる必要があった。
「複数のシステムをまたぐ処理もあり、1つの処理が遅れるとその影響で他の処理も遅れるため、6時の再開に間に合わないこともありました」(石橋氏)
AWS環境に移行したことでリソースが柔軟に利用できるようになったため、同社は夜間バッチを廃止してオンラインによるリアルタイム処理を基本としたシステムを組むことにした。一部オンライン処理が重い部分は、メッセージキューイングサービスである「Amazon SQS」(Simple Queue Service)による非同期処理を加えている。その結果、夜間バッチ処理は必要最低限の締め処理などに限定され、大幅に減らすことができた。
石橋氏らは基幹データベースのオープンソース化にも着手する。同社は過去20年にわたり「Oracle Database」を使用しており、チューニングを重ねたシステムは「現状が最適な状態」と石橋氏は話す。
しかし、さまざまなデータを基幹システムと連携するため、このデータベースとデータレイクなどとの同期を取ろうとすると、データベースの負荷が増してオンライン処理のパフォーマンスが低下していた。そのため、データベースを含むデータ基盤をオープンソースソフトウェア(OSS)に移行し、最新のツールを使える状態にしてからデータ同期を進める計画を立てた。
OSS化については、既存の基幹システムの標準コンポーネントも含めて移行する必要があるため、膨大な作業が発生してしまう。そのため標準コンポーネントはAPI化して疎結合化し、業務アプリケーションを移行しやすくした。約400のコンポーネントを2025年7月までにAPI化し、アプリケーションも順次オープン環境に移行する予定だ。
「当社はAPIの実装に慣れていないため、ノウハウが不足して時間がかかっています。これから習熟してテストの自動化なども進めたいと考えています」(石橋氏)
また、前述したように同社の基幹システムには、業務ドメイン間のデータ参照を禁止している独特の事情によって、データの提供側の工数が増加している課題がある。石橋氏は「データ統合ツールを導入してデータの収集をスピードアップさせます。データのコピーによる反映の遅れをなくすために、各ドメインから共有できるデータベースとしてデータの鮮度を高め、コピーを減らすつもりです」と話した。
サントリーグループは今後、オープン化に対応し、クラウドデータウェアハウス向け形式としてデファクトスタンダードになりつつあるApache Iceberg形式のデータ保存を基本にしていきたいという。「データの提供側は基本的にIceberg形式のデータを置いてもらうだけで、利用側が自由に活用できるようにしたいと考えています」(石橋氏)
サントリーホールディングスの齋藤 陽氏(デジタル本部 情報システム部部長)は、同社の今後の取り組みについて以下のように話す。「市場はさらなるスピードやサステナビリティを求めています。変化に強いシステムを実現する。AWSの無尽蔵に使えるスケーラビリティ、最新技術の取り込みやセキュリティへの対応の早さなどが期待されています。当社が使えていないテクノロジーはまだたくさんあると考えています」(齋藤氏)
石橋氏は最後に、「当社はAIなどの新技術にはまだ強くありません。今後、AWSユーザーとの情報交換を通じて活用できるようになりたいと考えています」と話し、講演を締めくくった。
トヨタが直面した生成AIの限界 克服目指し業務特化型RAG SaaSを構築
AWSが日本に2兆円投資する理由 大規模イベントで語られた未来の姿
SAPの「2027年問題」、メルセデス・ベンツ・グループはどう解決した?【事例紹介】
メインフレームは「不死鳥」か? 延命を後押しするのは“あの技術”Copyright © ITmedia, Inc. All Rights Reserved.