こちらに参加したのでなう書きます
オープニング(20分)
「ファーストリテイリングにおけるビジネスの変革とデジタルの取り組みについて」
株式会社ファーストリテイリング デジタル業務改革サービス部 執行役員（CTO 兼 CSO） 大谷 晋平 氏
会社概要
・ユニクロ、GUをはじめとするブランドでグローバルに展開中
・世界3位のシャア
・世界中でlife wearへの支持が拡大
ミッション
服を変え、常識を変え、世界を変えていく。
・life wear
あらゆる人の生活を豊かにする
・Peace for ALL
ルメール、安藤ただお
被害を受けた方に還元
・有明プロジェクト
情報製造小売業への変革
情報を商品化してお客さまが欲しいのもを届ける
お客さまが本当に欲しい服が欲しい時にそこにあってすぐに買える
微細な声から随時届ける、必要な分だけ届ける
コミュニケーション基盤を整える
情報を一元化
2016年からやっている
エコシステムをエンドツーエンドで
エンジニアはその中心
・デジタル業務改革サービス部について
業務のあり方そのものを変える
業務→システム→活用
データ分析を最近増やしている
取り組み事例
・ユニクロRFIDのレジ
・サプライチェーン
自動走行
幅広く活動中
各部署の取り組みのご紹介(2時間10分)
「ファーストリテイリングの内製化の進化」
株式会社ファーストリテイリング デジタル業務改革サービス部 コアエンジニアリングチーム 部長 村田 雄一 氏
株式会社ファーストリテイリング デジタル業務改革サービス部 コアエンジニアリングチーム リーダー 余 嘨 氏
なぜ内製化するのか
プラットフォームは自分たちで持たなきゃいけない
誰かに任せるとブラックボックスになってしまう
・業務＝システム
システム開発の本質
・システムの人間が、現場より現場を理解していること
・長期的に矛盾しないこと
・小さく始めて学びを蓄積
会員基盤→カタログサイト→オンラインストア→・・
段階的に
組織面
・グローバル人材を積極的に採用
・公用語としては英語
・会議に同時通訳
内製化＝正社員だけ じゃない
社員とパトナーが一緒になって
人材育成
・ユニークなカルチャー
・全員経営
会社のビジネス戦略を理解し、それを支える技術的な意思決定に反映させること アーキテクトエレベータ
内製化による成功体験
・問題解決のスピードが圧倒的に早い
自分で作成したので当たりがつく
・コントロール
内部まで理解しているので全てをコントロールできるの
課題
・様々なカルチャーギャップの克服
日本とグローバルを統合するリーダーシップ
・グローバルなスケール
簡単に人を雇って組み直すことが難しい
規模やタイムゾーンの違い
これから
・年間売り上げを10兆円を支える組織を日本初で作ろうとしている
・エンジニアにとってやりがいがある職場をつくろとしている
「グローバル展開×店舗とECの融合×売上10兆円への事業成長を支えるマイクロサービスプラットフォーム
株式会社ファーストリテイリング デジタル業務改革サービス部 コアエンジニアリングチーム リーダー 余 嘨 氏
株式会社ファーストリテイリング デジタル業務改革サービス部 コアエンジニアリングチーム 井上夏樹 氏
以前は各地域で異なるソリューションを使用していた。
別々の管理なので、時間とお金がかかり非効率。
2017年から、グローバルなプラットフォーム
どの国のユーザでも同じUXできる
歴史
カナダに小規模リリース
後に、日本に大規模リリース
ECの機能
・FRが他と違うところは、実店舗があるところ
O2O 店舗とECの融合
リージョンごとの支払い方法
ライフステーション
基本方針
マルチブランド対応
サービスレベルを統一
O2O
online to offline、offline to online
お客様が店舗で在庫がなかった場合、ECの在庫から取り寄せできる
①店舗受け取り
EC在庫利用
配送料なし物流コスト削減店舗への誘導
②オーダ&ピック
店舗在庫利用
配送料なし物流コスト削減店舗への誘導
ビックセールする時に限られた在庫で運用
③店舗配送
店舗在庫を利用
ECに在庫がない場合でも店舗の在庫を使用できる
システム構成
・責務の分解
フロントはそれぞれのブランドで作成
バックエンドはプラットフォームとして作成
・リクエストフロー
それぞれのクライアントがBFFを保持
「ファーストリテイリングのITを支えるAWS インフラストラクチャ」
株式会社ファーストリテイリング デジタル業務改革サービス部 インフラストラクチャチーム 部長 堀川 茂 氏
なぜクラウドが必要なのか
世界中に3500店舗以上の倉庫がある
すべてのサプライチェーンをつなげるために必要だった。
ユニクロの公式サイトが3日ダウン
オンプレを使用していた。
キャンペーン期間中なのにサーバダウンしてしまった。
クラウド利用推移
オンプレ環境で運用していたので、
2013年老朽化によりパフォーマンス障害が発生するようになった。
大規模インスタンスの管理が必要だった。
クラウドで何を達成したか
・簡単なスケーラビリティ
・クラウドシフトできた
・AWSエンジニアの確保が容易
・BCPサイトを簡単に構築できる、システムの堅牢性が上がった
・繁忙期、閑散期のリリース調整可能となった
AWSの利用概況
AWSアカウント数60以上
リージョン15以上
コンピュート数15000以上
データベース数3000以上
コンテナ数120000以上
インフラチームの役割
横断で関わる仕組みづくりをおこなうチーム
少数精鋭で大規模クラウドを運用するコツ
アーキレビュー
業務、アーキ、インフラが一堂に集まる
レビュー観点
・プロジェクト計画
・導入スコープ
・アプリケーションアーキ
・インフラアーキ
・インテグレーションアーキ
・運用
・セキュリティ
レビュープロセス
出来たものを見るだけじゃなく、
レビューアがアドバイスする。
システム規模
自動化が必要
大規模化に伴う諸問題
・手動
・誰が何を作ったかわからない
・サポート終了で受けられない
・所有者がわからない
・同じような仕組みが散財
・横断的な状況把握ができない
・セキュリティの問題
自動化、高度化の取り組み
・デプロイ
インフラチームが依頼をもとに作業をしていた。
アプリケーション側に権限委譲
デプロイパイプラインの標準化
・コスト管理
タグを使って管理
アプリケーション側にも開放して是正
・組織配下で管理
lacの徹底とセルフサービス化
パイプラインを標準化
権限を最小化して責任分解
アプリケーション側に責任移譲
更なるセルフサービスへの挑戦
EKSベースの仕組みを再作成中
より進化したセルフサービスを構築中
大規模なインフラ管理のコスト
システム毎にコストを管理できる
システム監視基盤の統合
バラバラに存在した監視基盤を統合
データドックに情報を集約し、アプリケーションの異常な振る舞いを検知
AWSサービスを利用したセキュリティ対策
・脅威検知から解決までマルチアカウントで全部ON
・セキュリティアカウントに全てを集約
・事前に検知分析して対応推進できる
今度の戦略
グローバルでいかに貢献できるか
海外が体勢が弱いので、強化のための教育啓蒙ノウハウの蓄積を強化中
日本の深夜時間は別の国でフォローができるようなチームを構築中
AWS様への期待
世界NO1アパレルカンパニーに向けて、よりグローバルな視点でAWSとの協業を深めたい
「ユニクロ・GUのECアプリの裏側をご紹介」
①AWSを活用したキャッシュベースのアーキテクチャによるパフォーマンスのボトルネックの解決
株式会社ファーストリテイリング デジタル業務改革サービス部 コアエンジニアリングチーム 秋元 俊祐 氏
カート機能
アイテムのカート投入からオーダ作成までの情報を一元的に管理
旧アーキテクチャ
DBはPostgreSQL、キャッシュはRedis
課題
ログインをしなくても誰でもカートを作成できるため、
高トラフィックに晒されやすい
セール時にトラフィックで性能が飽和状態
DBが性能ボトルネックになり、コストも圧迫
ソリューション検討
DBの性能改善
DBスケーラアップを検討したもののすでに上位のものを使用していた。
コスト面は悪化する可能性
→ナレッジがなかったの
→最終的には、RedisをメインDBとして採用
シンプルなオペレーションのため
RDBを使わないので複雑なクエリ処理ができない
データ取得ができず、分析が困難
→RDBは残す事になった
新アーキテクチャ
定期的にRedisでアップデートされたカートを抽出して解決
・ 実装上工夫した点
ロックの実装
トランザクション管理
・データマイグレーション
ダウンタイム0で既存カートをマイグレーション
Amazon ElastiCache for Redisで管理
結果
性能向上した
2倍以上のトラフィックでも性能劣化なし
CPUの使用率の余裕からさらに5倍10倍もカバー可能
まとめ
Amazon ElastiCache for Redisで性能が改善された
②Amazon Opensearch Service を活用したグローバル・デジタルコマース検索の実現
株式会社ファーストリテイリング デジタル業務改革サービス部 コアエンジニアリングチーム 佐野 大輔 氏
・商品検索機能を提供するMS
・search platform
FRでよく使われているAWSサービス
1 オーロラポスぐれ
2 Elastic cache for Redis
3 Amazon Managed Streaming
Opensearchの特徴
柔軟な構造を持つデータを大量に登録することができる
長所短所
・長所
参照メインならOK
典型的な機能の実現に開発量が少なく済む
・短所
コストが高い
高度な検索処理に絞った方がいい
グローバルデジタルコマースの検索
・たくさんのブランドサイトへの展開
・世界展開 地域、言語 へのサポート
実現のポイント
・機能性
多言語対応
各言語の特性を考慮した検索を自前で実装するのは現実的じゃない
デフォルトで機能が実装済みであることが重要
・展開容易性
自動的に検索サーバに送られるようなアーキテクチャを構築することで、ヒューマンエラーやコスト削減
・拡張性
安全なスケールインアウトを実施するために、専用マスターノードが役に立った。
導入前はスケールインアウト時にセッション切断が発生するので深夜に実施していた。
導入後は切断が発生しない
・運用性
単語、シノニムを登録できる手段が必ず必要になる。
テキスト分析のためにこまめな登録が必要。
今後の課題は、シノニムの手動登録による運用コストの削減
UX向上のために、AI活用したりする
「データ連携基盤の実行制御を実現するAmazon ECSを活用したアプリケーション開発」
株式会社ファーストリテイリング デジタル業務改革サービス部 インテグレーションエンジニアリングチーム リーダー 阪本 圭 氏
株式会社ファーストリテイリング デジタル業務改革サービス部 インテグレーションエンジニアリングチーム 吉元 裕人 氏
どんな背景でどんなコンセプトなのか
今後のチャレンジ
インテグレーションエンジニアリンク チームの役割
・システム開発の効率化
・システム間データ連携の管理監督
背景
複雑化するJP1ジョブの依存性
エンドツーエンドでのデータ整流化、利活用の必要性
対応コンセプト
・大量データ処理の効率化
・ハブアンドスポーク型のクラウドネイティブなデータ連携基盤
・定義ベースでのルーティング制御
・全体最適化
・色々なプロトコル
求められる要件
・安定性
・大量データ処理に耐える
・可搬性
・多様なアプリケーションとのシームレスな連携
アプリケーション開発
開発経緯と課題と工夫
バッチ処理基盤として作成されている基盤
・管理画面等を追加したフレームワーク化
・コンテナ化
・動作環境の強化 k8sの並列実行
課題と工夫
・環境の再現性 どんなところでもビルドできるように
・インフラストラクチャ AS コード
・拡張性
・拡張可能性 柔軟なスケールアップアウト
・可搬性 タスク管理機能にクラウド依存をなくす
アプリケーション自身が実行状態を知る
・コンテナ内での実行制御の工夫
・同期的実行制御実現のための工夫
まとめ
EC2を動作環境として利用するのではなく、実行基盤として実行するようなアプリケーションにする
今後に向けて
・セルフサービス化
・新たなSaas等の外部ソリューションとの連携
パネルディスカッション：AWS と紡いできたデジタル変革の歴史 - ファーストリテイリングが積み重ねてきた経験と、これから生み出す新たなる価値(90分)
・株式会社ファーストリテイリング デジタル業務改革サービス部 執行役員（CTO 兼 CSO） 大谷 晋平 氏
・株式会社ファーストリテイリング デジタル業務改革サービス部 コアエンジニアリングチーム 部長 村田 雄一 氏
・株式会社ファーストリテイリング デジタル業務改革サービス部 インフラストラクチャチーム 部長 堀川 茂 氏
・株式会社ファーストリテイリング デジタル業務改革サービス部 インテグレーションエンジニアリングチーム 部長 北口 泰大 氏
・アマゾン ウェブ サービス ジャパン 合同会社 五十嵐 建平
黎明期-カルチャーの醸成
簡単要約
・AWS導入初期の経験
堀川さん: 初めてのAWS利用をセミナーやビジネスパートナー（BP）から学び経験を積んだ。
・レビュー仕組みの導入理由
堀川さん: 品質問題のため
北口さん: インフラ管理とリソースの適正管理、意思決定のため
・FRチームの初期活動
大谷さん:
有明の自動倉庫の立て直しから開始。優秀な人を集めて進行、課題中心の話し合いで連携強化。
初期時代の技術的挑戦
堀川さん: 4TBのデータ処理をAWSと協力して実現。
大谷さん: 当初99%オンプレ計画をAWSからの提案で変更。
・AWSのフィードバック重視
AWSはフィードバックを重視している。
対話内容
AWSを使ったことはなかった。
セミナー参加したり、使い方をBPさんに教えてもらった。
ひとつひとつ経験していった。
アーキテクチャレビュー時にも知見がなかった。（堀川さん
なんでレビューの仕組みを作ったのか（五十嵐さん
品質問題。（堀川さん
インラフを管理外でのリソース管理がちゃんとできるように、意思決定ができるように（北口さん
FRに入って最初にやったこと（五十嵐さん
有明の自動倉庫の立て直し。AWSに関係ないこと。
個人の能力で火消し（大谷さん
どうやってクラウドシフトしていったのか（五十嵐さん
自分一人じゃ回らないので、優秀な人を集めて行った。
カオスの中から進めていった。（大谷さん
どうやって綺麗にしたのか、人だけそろっても出来ないんじゃ（五十嵐さん
知恵を出し合えた。形状ではなく課題を中心に話し出したら横の連携ができた。最初からできた訳ではない。（大谷さん
初期時代のテクニカル（五十嵐さん
会計処理のトランザクション、データ量が4テラでおおすぎたので、
オンプレしか出来ないという思い込みがあったが、
AWSさんと大谷さんと交渉して実現できた。（堀川さん
99％オンプレで行こうとしていたが、
AWSさんからの強いご提案があった。（大谷さん
AWSはフォードバックを重視している（五十嵐さん
移行期-アーキテクチャの変更
簡単要約
・入社時のアーキテクチャ変更への感想と乗り越え方
北口さん：
クラウドシフトは完了していたが、アプリはクラウドネイティブではなかった
少人数で24時間365日運用するため、クラウドネイティブへの移行法を検討
・既存システムの作り直しのトレードオフ
大谷さん：
EDI基盤のグローバル統一に苦労
Beanstalkの不完全さから最新技術への移行が必須
・モダナイゼーションに対するビジネス層への交渉
大谷さん：
アマゾンで鍛えられた文章能力で交渉
パワーポイントをやめ、文章で明確に表現
・ECの内製化とアーキテクチャ変更
村田さん：
アーキテクチャを変更し、モノリスからマイクロサービスへ移行
個別リリース可能なプラットフォーム化を達成
・ECと店舗のシナジーの伝達
村田さん：ECと店舗は別物であり、シナジーを持たせると経営層に伝えた
・技術的な難題とその克服方法
村田さん：ビジネスロジックの複雑化は有識者から学び、トランザクション増加にはAWSのサービスを使用し対応
・規模拡大に伴う課題解決
堀川さん：
エンジニアの数、システムの品質、コスト増加に対応
アーキテクチャレビューで品質問題を解決し、課題に向き合う
・コスト管理の工夫
堀川さん：教育をシステム開発の必要経費として経営層に理解させ、能動的なコストチューニングを実施
・運用自動化
北口さん：労力を削減するため、yamlでの自動化ツールを提供
・クラウドネイティブ化の制約と経験
大谷さん：
LambdaとNoSQLを禁止し、コンテナで可搬性を高め、ナレッジ共有を重視
DockerとECSで対応
・スケールする構造と標準化
大谷さん：ルールで使用可能なサービスを制限し標準化
五十嵐さん：パターン化段階である程度の幅を持たせて決定
・失敗から学んだ標準化
大谷さん：失敗経験を基に標準化を進めた
対話内容
アーキを大きく変更しているが、
入社時にどう感じたのか、なぜやり切れたのか（五十嵐さん
入社時はクラウドシフトがほぼ完了していたが、
アプリがクラウドネイティブではなかった。オンプレをそのまま乗っけたみたいな構造。
24365で少数精鋭でどうするか、クラウドネイティブでの運用実行方法を検討する必要があった。（北口さん
出来ているものを作り直すにはトレードオフがあったのでは？すんなりいった？（五十嵐さん
北口さんはEDI基盤。グローバルで統一しないといけなかったという理解を会社に示すには労力がかかった。
当時のビーンズトークは穴かあった。
最新の技術への移行が必須だった。（大谷さん
モダナイゼーションに対するビジネス層への交渉（五十嵐さん
アマゾンで鍛えられた文章能力が生きた。
パワーポイントをやめる。文章で書き切ったものじゃないと信用されない時代。はっきり書き切る。（大谷さん
どんな取り組み（五十嵐さん
ECの内製化について、内部詳細について把握して対応する。
内製化を推進するにあったってアーキテクチャを変える。
ECサイトをプラットフォームにしていく。モノリスからMSへ。
個別リリースができるようになった。（村田さん
ECのプラットフォームかすると店舗のO2O
EC側に大きな投資をしてどうするのかという顧客の質問にどうした（五十嵐さん
店舗側とのコミュニケーションより、経営層とのコミュニケーション。
店舗からはECが流行ると店舗での仕事がなくなるという不満の声を受けた。
しかし店舗とECは別物で、シナジーと伝えた。（村田さん
技術的に難易度がかかったことをどうクリアしたのか（五十嵐さん
①ビジネスロジックの複雑化
→有識者から学んだ。
②スケール
→コロナにより急激なトランザクション増加
AWSのサービスを使用したり、普通じゃない仕組みを構築したりした。
（村田さん
規模が大きくなるにつれて課題の解決方法（五十嵐さん
人ものかね全部課題があった。
エンジニアの数やシステムの品質。コストが急激に増加。
品質はアーキテクチャレビュー等で解決。
日々課題について向き合って、課題に向き合って解決する。（堀川さん
コストについての特別な工夫（五十嵐さん
教育はシステム開発の必要経費であることを経営層へ理解してもらう。
自らが能動的にコストをチューニングできるようにする。
いざとなったら大谷さんがズバッと言う。（堀川さん
運用するにあたっての運用自動化（五十嵐さん
労力がかからないように、yamlでの自動化等のツール提供を行う。（北口さん
コストについてガードレールを設定しているのか（五十嵐さん
システムを使用しているのは業務を使っている人であり、
そのメンバとは常にコミュニケーションしながら開発していた。（北口さん
クラウドネイティブにするにあったって、話題に出てないもの（五十嵐さん
Lambdaの使用を禁止。コンテナで可搬性を高めるため。
ノーsQLも禁止。
少数でやっているのでナレッジ共有ができるように。
dockerは大変だったけど、やってよかった。
ECSがなかったら出来なかったかも。（大谷さん
スケールする構造を作成した上で、グローバルなものがあった？（五十嵐さん
色々なサービスがあったが、使用できるものはルールで制限した。
標準化した。（大谷さん
標準化は同時にした？（五十嵐さん
枠を決めていた。（大谷さん
パターン化出来てきた段階で、統一していった？（五十嵐さん
1こで決めちゃうと難しいので、ある程度の幅で決めた。（大谷さん
標準化してから決めた？（五十嵐さん
失敗した経験則から決めた。（大谷さん
拡張期-グローバル化
簡単要約
・スケールと個別対応の難しさ
村田さん：
法律や交通の違いにより地域ごとに適用が異なる為、スケールと個別対応が難しく、効率化とグローバル適用の検討が重要
・グローバルとローカルのバランス
村田さん：局所最適を下げ、世界で最適なシステムを作成する共通認識を持つ
・技術的挑戦と自動化
村田さん：技術で難題を解決し、自動化を推進することで展開を容易に
大谷さん：AIや法規制問題で経営の巻き込みが必要
・AWSのネットワーク最適化
堀川さん：以前は東京に集約していたが、今は各リージョンを活用して低レイテンシーを実現
・グローバル適用とカスタマイズ
北口さん：
グローバル適用と各国カスタマイズが多く、税制の違いが課題だったので、ナレッジを蓄積し、段階的に対応するスクラップアンドビルド方式
・チームインクルージョン
北口さん：外国籍のメンバーが多数所属し、会社のカルチャーを理解するメンバーで構成
・会社文化の共有
大谷さん：課題解決に向けたコミュニケーションが重要
村田さん：価値観共有の強化と教育で、ミッションステートメントの共有を重視
・セキュリティ対策
大谷さん：セキュリティ水準の向上と経営層の意識改革が必要なので、時代に応じたセキュリティと柔軟性バランスの確保
対話内容
1番はなに？（五十嵐さん
スケールと個別対応が難しい。
適切なプライオリティーをつけて効率化できるような検討が重要。
グローバルで作ったものが必ずしも地域で使えるというわけではない。
法律や交通等が異なる。（村田さん
グローバルとローカルのバランス（五十嵐さん
一つのシステムを作成するのではなく、世界で1番いいものを作成するという共通認識を持つ。
局所最適はプライオリティを下げる。（村田さん
技術テクノロジー面での難所（五十嵐さん
逆に難しい問題を技術で解決していく。
徹底的に自動化することで、世界での展開を容易にする。（村田さん
グローバルを検討する際に、AIの採用や法律等の問題で、
技術検討を経営側を巻き込む必要が出てきている。（大谷さん
AWS大規模なネットワークの工夫（五十嵐さん
昔は東京に集約していたので海外からの接続が遅かった。
今はクラウドのネットワークをフル活用。
各リージョンを使って低レイテンシーを実現。（堀川さん
規模が大きくなってからネットワークの工事？（五十嵐さん
そう。（堀川さん
北口さんの領域での工夫（五十嵐さん
グローバルだけど各国カスタマイズが多い。
税金の仕組みが違う。（北口さん
グローバルとカスタマイズとの境界は当たった？（五十嵐さん
ナレッジが溜まった段階で作り出している。（北口さん
世代管理している？（五十嵐さん
スクラップアンドビルド。古いのは全部捨てている。（北口さん
チームメンバは日本の方？（五十嵐さん
過半数が外国籍の方（北口さん
インクルージョンの工夫（五十嵐さん
会社のカルチャーを理解している人で構成している。（北口さん
カルチャーについて（五十嵐さん
課題解決の一環としてコミュニケーションしている。
その考え方があっていれば大丈夫。そこが大事。（大谷さん
外国籍の方が多い。
本当に大切にするものを共有できてないと意思決定ができない。
根底の価値観を揃えることに力を入れている。
会社文化を紹介するような教育がある。（村田さん
ミッションステートメントを共有することを大切にしているんですね（五十嵐さん
CSOとして（五十嵐さん
会社全体で見てもセキュリティの水準を上げる必要がある。
経営層の意識もそうだし、フィジカルセキュリティが必要。
ITとして運用して、お客様情報を運用する事について
俯瞰してみる。
何のためにやっているか、ブレないように文化形成の必要がある。
課題も多いし、政府等との関係性作りも必要。（大谷さん
セキュリティは時代に合わせて変えなきゃいけないけど、
キツくなると柔軟性がなくなる（五十嵐さん
露骨に失わないようなバランスの取れたセキュリティが必要（大谷さん
最後に
今の機能に注目するのではなく、将来的にどう進化するのか意思決定する必要がある。
それに必要なのは、会社の文化を知る必要がある。
AWSは小売からスタートしているので、FRと波長が合う。
それぞれの会社のカルチャー、こだわりを理解して製品選定が必要（村田さん
AWSさんの安定な基盤提供に感謝。
本日、大事にしている考え方を共有できたと思う。
新しいサービスを使いたいと思うが、ITが目的じゃなく手段であり、
AWSのサービスや他クラウドとの選定を行なっている。（北口さん
よりグローバル化するためにコミットするミッション。
AWSさんとタッグを強化したい。
FRとのカルチャーが似ている。重要なコンセプトが似ている。
より戦略的にタッグを組んでいきたい。（堀川さん
AWSとも十二年の付き合い。ほとんどAWS。総論満足している。
カルチャー、特徴をうまく取り込むと良い。
AWSさんに無茶振りをしていくと良い回答がもらえる。
AWSの可能性を最大限に使えるように（大谷さん