100円ショップ「ダイソー」を運営する大創産業は2018年2月、オンプレミス(自社所有)環境のPOS(Point Of Sales)システムを、AWSに移行し本稼働した。システム基盤にPaaSを採用し、仮想サーバーを使わないサーバーレス化を実現している。

 大創産業は国内に3150店、海外の26の国・地域に1900店を展開し、7万点の商品を取り扱う(いずれも2017年10月時点)。今回サーバーレス化したPOSシステムは、多数の店舗からのPOSデータを受け取り、発注業務などに活用する大規模かつ重要なシステムだ。

 POSシステムをAWSに移行するに当たり採用したPaaSは、サーバーレスコード実行サービスの「AWS Lambda」、NoSQLデータベースの「Amazon DynamoDB」、メッセージキューイングサービスの「Amazon SQS」、プッシュ通知サービスの「Amazon SNS」など。これらのPaaSを組み合わせて、新POSシステムの基盤を実装した(図1)。

図1 POSシステムをオンプレミス環境からサーバーレスへ
[画像のクリックで拡大表示]

 新POSシステムは、店舗から送られるPOSデータを受け取り保持するサブシステムと、参照系のサブシステムで大きく構成される。サブシステム内もデータの受け取り、各種チェック、保持などといった役割ごとに分割することで、改変しやすいシステムにした。

障壁(1)
1枚岩のシステムが壁に 改変しやすい設計を模索

 大創産業がPOSシステムの刷新に取り組んだのは、2015年に構築した発注システムの改修で苦しんだ経験からだ(図2)。

図2 AWS活用の主な経緯
[画像のクリックで拡大表示]

 発注システムはオンプレミス環境のPOSシステムとは別に、一部機能を切り出してAWS上に構築した。プロジェクトの実務リーダーを務めた情報システム部システム開発1課の丸本健二郎課長は、「オンプレミスのPOSシステムは2年間のデータを扱えるが、AWS側は1カ月分のデータしか扱えなかった」と語る。

 当初はPOSシステムの一部と出荷、入庫、発注といった五つのサブシステムに分け、システム改変しやすい設計を考えた。データ分析には、DWH(Data WareHouse)サービスの「Amazon Redshift」を採用した。

 ところが、実際は全ての機能がモノリシック(一枚岩)なシステムになった。丸本課長は組織の構造が設計に反映されるという「コンウェイの法則」を引いて、当時の失敗を振り返る。「1チームに五つのシステム構築を任せたため、納期の関係もありモノリシックなシステムができあがった。本来はシステムごとにチームも五つに分けるべきだった」。

マイクロサービスに変更

 アプリケーションのソフトウエアコンポーネント同士が互いに強い依存関係を持つモノリシックなシステムだと、部分的な機能変更でも広範囲に影響が及ぶ。

 そこで、システムを適切な単位に分割して独立性を高めることにより、機能変更しやすくする「マイクロサービスアーキテクチャー」に基づき、オンプレミス環境のPOSシステムを刷新。AWS上のPOSシステムの一部と入れ替えることにした。

 検討段階ではインフラ管理の手間を減らし、スケールアウトしやすいシステムにするため、サーバーレス化の全面採用も決めた。

 サーバーレス化に踏み切ったのは、「2017年に商品管理システムの一部をマイクロサービスとして切り出し、既にサーバーレス化した経験があったから」と丸本課長は語る。

 新POSシステムでは主にAmazon SNS、Amazon SQS、Lambdaを使い、サービス間の連携を非同期にすることで、各サービスの独立性を高めた。データの受け取りから保持の流れは図3の通り。

図3 役割ごとに分割してシステムを構築
[画像のクリックで拡大表示]

 店舗から送られるPOSデータは、「RedPost」という独自インタフェースシステムを介して、オブジェクトストレージの「Amazon S3」に蓄積される。

 RedPostはEAI(Enterprise Application Integration)、EDI(Electronic Data Interchange)の役割を担う。丸本課長は「店舗から送られるデータはファイル形式や転送方式がばらばら。RedPostを経由することでCSV(カンマ区切り)形式でS3に保存する」と説明する。

 S3にデータが保存されると、それをきっかけにSNSがSQSにメッセージを送る。Lambdaは定時起動し、SQSをポーリングしてメッセージを受信する。Lambdaは、コード実行のリクエストを受け付けるたび、バックエンドでコンテナを1台起動させてJavaScriptなどの指定コードを実行する。

 受け取りではLambdaはCSV形式のファイルをS3に保持し、SNSを介して受け取りが完了したメッセージを次の役割を担うSQSに送る。

 保持チェックでは、同一のPOSデータをS3に二重保持しないよう「重複チェック」を行う。「誤って店舗から重複データが送られた場合でも、ここでチェックすることでデータの二重保持を防ぐ」(丸本課長)ためだ。

 店舗からPOSデータが届くたびに、Lambdaのコンテナが起動してコードを実行。重複チェックをしたうえでS3にPOSデータを保持する。

 一方のDynamoDBは、POSデータが保持済みであることを示すフラグの格納場所として使う。つまりDynamoDBはS3に保持済みのPOSデータのレシート番号を保持する役割を担う。

 Lambdaは、取得したPOSデータのレシート番号がDynamoDBにない(S3に未保持である)ことを確認したうえで、S3に保持し、DynamoDBにレシート番号を書き込む。

 重複チェックが終われば、LambdaとSNSを経由して、さらに次の役割を担うSQSに終了の通知メッセージを送る。最終的に売上日別と取込日別に分けてS3にデータを保存する。

この先は有料会員の登録が必要です。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら