【開催報告】 ファーストリテイリングにおけるデジタル改革の取り組み 〜AWSを活用したエンジニアリング組織の変革〜 (Part 2)

アマゾン ウェブ サービス ジャパン株式会社は 2021年9月2日に株式会社ファーストリテイリング様をお招きし「ファーストリテイリングにおけるデジタル改革の取り組み」というテーマで、2時間に渡ってファーストリテイリングの皆様にご講演をいただきました。前回に引き続きこのブログでは講演の後半をレポートさせていただきます。

ファーストリテイリングを支えるバッチ処理基盤とデータ連携基盤

株式会社ファーストリテイリング デジタル業務改革サービス部 インテグレーションエンジニアリングチーム リーダー 北口 泰大 氏

このセッションでは、ファーストリテイリング様の共通基盤プラットフォームであり大量のデータを処理するためのバッチ処理基盤と、EC／店舗／サプライチェーン／バックオフィスを繋ぐためのデータ連携基盤を内製開発し、今もグローバルに継続進化させている取り組みをご紹介いただきました。

バッチ処理基盤は、複数のタスク処理を制御する基盤のことで、「スケジューラ」「分散制御」「処理順序制御」「ステータス管理」といった機能が必要です。内製化に至った経緯としては、

• 複雑化する JP1 ジョブの依存関係の簡素化
• 定められた時間内での大量のデータに対する並列分散処理実行
• ブランド別・タイムゾーン別・事業別の優先度制御

が既存の商用製品のみでは実現が難しく、中間層のバッチ処理基盤を作り、より効率的なバッチ処理の管理を実現する必要がありました。

システムは Amazon Elastic Compute Cloud (Amazon EC2) 、Amazon DynamoDB、Amazon Simple Queue Service (SQS) 、Amazon Elastic Container Service (Amazon ECS) 、Amazon Aurora、AWS Lambda により構成されていて、スケジュールの機能だけ既存商用製品を用い、既存商用製品からのトリガーによりバッチの処理が始まるという機構になっています。

• 既存商用製品サーバから SSH 越しに EC2 インスタンスに用意したプログラムを実行して、DynamoDB にレコードを追加すると、DynamoDB Streams のイベントが発火して、紐付けられた Lambda ファンクションが処理を開始する。
• Lambda は DynamoDB のレコードの内容を評価して、メッセージを作り、SQS にメッセージを put する。
• ECS サービスとして常駐的に動いている Java アプリケーションがあり、SQS をロングポーリングして、Lambda がEnqueue したメッセージを Dequeue する。そのメッセージの内容に書かれている情報とDBに格納した定義情報を用いて実行すべきタスクとそのタスクに与えるパラメータを特定し、実行する。
• Java アプリケーションの中に業務ロジックの実装はあまり持っていない。外側に REST API として業務ロジックの実装を持ち、依存関係解決は Java アプリケーションにあるが、業務ロジックは外側の REST API の実装に委ねるという機構をとっている。
• コントローラの Java アプリケーションから呼び出された業務ロジックは、業務ロジックの処理完了後、コントローラに業務ロジックの成功失敗のステータスを戻す。それを処理履歴として Aurora の DB に永続化して、後続タスクの依存関係を解決した上で、次に動かすタスクのメッセージを Enqueue する。

これを繰り返してタスクの連鎖が回って行きます。DynamoDB の一つのレコードは複数のタスクから構成される一連のタスクフローに相当し、タスクフローの最終タスク実行後には DynamoDB のレコードを更新し、DynamoDB Streams  のイベントで発火した Lambda が既存商用製品に完了を返します。

また、このバッチ処理基盤は、複数の SQS のキューを一つの Java アプリケーションで Consume できるようにしています。Java アプリケーションのメモリ上でもキューを持っていて、SQS のキューに対して優先度を設定しておくと、実際の処理を実行する際は、優先度の高いものから順に処理していくという機構をとっています。ユースケースとして、並走する異なるタイムゾーンの夜間バッチ処理において、現地時間の朝方に終わるという要件に応えるために、東のタイムゾーンの国の処理から優先的にバッチが終わるようにしていることをご紹介いただきました。

次に、このバッチ処理基盤を用いて、社内と社外システムの連携をするデータハブシステムを内製した事例をご紹介いただきました。サプライチェーンの上流下流や会計システムなど、ひとつのシステムがひとつのデータだけで成り立つことは少なく、システム間データ連携が多いため、End-to-End で運用することに課題があり、データ連携基盤を立てることでハブ＆スポーク型で設計し直されました。

インバウンドの処理とルーティングの処理とアウトバウンドの処理をタスクフローとして定義して、イベント駆動でリアルタイムに連携しています。P2P でつながずにデータハブが中継することで、ひとつのインバウンドを複数の受信先に同報させることや、受信先ごとに違うプロトコル・フォーマットで受けることが可能になっています。プロトコルの差異を吸収する層として機能しているほか、例えば連携先のひとつは CSV、ひとつは XML などフォーマット差異の吸収を行っているとのことです。あるシステムが移行をかけるときに、新システムと旧システムでプロトコルなど仕様が違うことがあるので、送信元のシステムには影響を及ばさずに、新システムと旧システムを並行稼働することができるという利点をご紹介いただきました。

内製エンジニアリング組織の構築とこれから

株式会社ファーストリテイリング デジタル業務改革サービス部 コアエンジニアリングチーム 部長 平岡 大輔 氏

最後のセッションでは、ファーストリテイリングがグループ・グローバル統一プラットフォームを内製開発に移行するにあたって、背景や直面した課題、解決のためのアプローチと今後のチャレンジについてご紹介いただきました。

コアエンジニアリングチームでは、「LifeWear を最先端の技術で世界中のすべての人々に届ける。ビジネスの課題を技術で解決する世界一流の専門チームとなり商売に貢献する」というチームのミッションステートメントのもと、主にコマースプラットフォームの内製開発が行われています。

この内製開発に取り組んだ理由として、以下のポイントをご紹介いただきました。

• 迅速かつ継続的な開発：開発スピードを上げることができる。
• 運用マインド：開発だけではなく運用してちゃんとビジネスに貢献したのかを見ながらシステムを調整する。

業務知識を活かした積極的な貢献：ビジネスを知っているからこそできる貢献や、創造的で革新的なソリューションの提案が行える。

その際、AWSを活用することによりスケーラブルなシステムをグローバルに迅速に展開することが可能となり、バリューを出す領域によりフォーカスすることができたとのことです。

改めてになりますが、内製開発のメリットとして、まずデリバリーのスピードや柔軟性・拡張性、コストがあります。そして、品質に関しても、ベンダー依存開発ではビジネス要件を正確に実装しようとしてアーキテクチャや実装が複雑になる一方で、内製開発だとビジネスとの妥協点を見つけてシンプルなソリューションを提供できるケースが多くなり、結果的に品質の向上ができます。

内製開発の定義も人や立場によって違いますが、ファーストリテイリングにおけるコマースプラットフォーム開発では、ビジネス要件の策定からアーキテクチャ の設計までは社員が行い、実装の部分はパートナーと協力して行う体制を敷いています。そして、この内製開発への期待としては、「お客様の要望に素早く対応できるプラットフォームをベースに業務改革マインドに溢れたシステムの中身を理解するエンジニアが業務と一体となって商売に取り組む体制を構築する」ということを挙げられました。

次に、内製化に向けての課題とその解決のアプローチについてもご紹介いただきました。採用においてファーストリテイリングの取り組みを認知してもらうことや、グローバルに開発者を集めるための英語でのコミュニケーションの必要性などがありました。また、ベンダー依存開発時にはあった厳格なインフラ運用を段階的に緩和し内製開発者がインフラにさわりやすい運用に変更する必要もありました。

その他、不明確であった役割・プロセス・ガイドラインの整備のほか、エンジニアのキャリアパスの設定などがあったそうです。特に、いわゆる請負根性から脱却し、内製開発のマインドに変えていく必要があるということでした。中でも、人材確保のために開発組織のグローバル化が必須であり、英語でのコミュニケーションやドキュメントの英語化を基本としているとのことです。そして、チームが大きくなることによってチーミングが重要になります。マイクロサービスごとにチームを作り、コアとなる人をリードにアサインして、メンバーやパートナーメンバーも同時にアサインして、マイクロサービス単位のチームを段階的に追加するという手法を採用されています。そして、システムの重要度に応じて内製の関与を高める、ハイブリットな内製開発構成をしています。ビジネスのコア（ヒト、モノ、カネ）や変化・拡張が想定されるものを優先して内製化してきたそうです。今後はビジネスの改善系にもフォーカスしていきたいとのことです。

内製化がもたらした成果としては、これまで幾年にもわたって組み上げたシステムを機能劣化せずにマイクロサービスの方式に無事に移行できたことの他、中身を知っているからこそ新しい課題の解決や新サービスのリリースまでが早いことや、技術・運用ノウハウの蓄積によるチーム成長と、それをベースに次のチャレンジ・会社への貢献が可能である、ということを共有いただきました。

最後に、将来の内製開発エンジニアに向け、

1. チャレンジ：最高水準のコマースプラットフォームの構築（リアル店舗とECがシームレスに連携した最高のUXの実現）、グローバル・ワンのソリューションを全世界、全ブランドに展開・運用、デリバリーのスピード、質、量をあげビジネスに貢献、ビジネスを深く理解し、エンジニアリング発の課題解決、コマース領域を超えてビジネスに貢献すること
2. 学習機会：グローバルかつ大規模ユーザーベースのサービス開発、大規模トラフィックをマネージするための技術、英語によるコミュニケーション、リアル店舗とECの融合サービスを学べること

というメッセージをいただきました。

クロージング

株式会社ファーストリテイリング デジタル業務改革サービス部 執行役員（CTO）大谷 晋平 氏

ファーストリテイリングにおけるエンジニア職種は大きく分けると、インフラエンジニア、システムアーキテクト、アプリケーションエンジニアの三つの職種になります。そのコアにあるのはブランドへのつながりや共感、知らないものへの好奇心・チャレンジ、異なる職種の方と一つのチームになり、共に働いて成果を出していくマインドセットを重視しているとのことです。

そして、日本発で事業変革を進めていくために、「攻めの IT で世界一へ」と本気で考え、クラウドの技術も最先端技術もふんだんに活用されていく方針を強調されました。

最後に、共感したエンジニアの皆さんにジョインしてもらいたいという熱意のこもったメッセージをいただき、ご講演を締めくくっていただきました。

最後に AWS からの質問にもご回答いただきました。

質問１) 感謝祭セール等、大量のトラフィックが予想されるイベントに備えて、アーキテクチャ上または運用上でなにか工夫されていることはありますか？

回答１) 感謝祭や突発的な非常に大きなイベントがある時は、様々な対策を取っている。まずシステムの前提として、全てデフォルト自動でスケールするために、AWS の Auto Scaling の仕組みを使っている。ECS をメインに利用し、Auto Scaling を設定して、どのようなトラフィックでも耐えられる対策をしている。加えて、突発的なイベントやトラフィックは我々が予期しない形で発生するので、突発的なトラフィックに備えて事前暖機のようなものをしている。特に特定の商品の発売時間前だったり、Push 通知の配信の前だったりとか、Auto Scaling による自動化以外にも、一時的に引き上げや引き下げをしている。

また、お客様にご迷惑をかけないという観点から、経済合理的ではないトラフィックが来た場合に流量制限の仕組みを持っており、Auto Scalingと流量制御を組み合わせてビジネスのネガティブインパクトが出ないように見守りながら運用している。特に大きなイベントの場合、大きなトラフィックを想定し、事前に性能試験を実施するなど、開発チームとDevOps チームが連動して常に準備を怠らないようにしている。実際に性能試験を行った結果と、実際のトラフィックとの両方をもとに毎日振り返りながら次に生かすサイクルを回している。

質問２）グローバル展開における AWS 利用のメリットはありますか？

回答２）AWS は展開しているリージョン数が非常に多くグローバル展開する時に積極的に活用している。ファーストリテイリングのビジネスは日本のみならず、グローバルに広がっているので、様々なリージョンを使っている。セキュリティやサービス内容が一貫していることから、非常にメリットを感じている。加えて、昨今 GDPR のような各国のレギュレーションが非常に厳しくなってきているのでこれらをクリアする時、AWS で様々な Certification をクリアしているのも大きなメリットと感じている。AWS 側で全体的に取り組んでいるところが、事業のサービスのレベルを上げ、お客様に迷惑をかけず安定的にトラフィックを提供してサービスを提供できていることがメリットと考えている。

質問３）多国籍のエンジニアチームのコミュニケーションにおいて、英語以外で最も難しい点はどこでしょうか？

回答３）平岡のセッションにあったように内製組織を作り上げることは正直簡単ではない。グローバルのメンバー、外国籍の方が多くなると英語・日本語という違い以外でも、根底にある仕事への価値観や働き方、ゴール設定の仕方の違いがある。簡単な解はないという認識を持っており、日本のメンバーも含め全てのメンバーに英語を覚えてもらう・相互理解のためのコミュニケーション・ファーストリテイリング の考え方の理解など様々な取り組みをしている。それらを通して、共通の文化を形成していったり、今ある問題に対して膝詰めで話し合ったりといったことを一つ一つ、丹念に取り組んでいくことが欠かせないという認識だ。簡単な回答はないが、こうしたことを楽しめるかどうかがグローバルの内製開発組織を作っていくにあたって重要と考える。そのようなマインドセットを持って前向きにやっていこう、と日々話している。

本ブログは、 アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 柏村、國田、国政が執筆しました。