基幹業務もHadoopで!! -ローソンにおける店舗発注業務へのHadoop + Hive導入と その取り組みについて-

基幹業務もHadoopで!! -ローソンにおける店舗発注業務へのHadoop + Hive導入と その取り組みについて-

1. 1. 基幹業務もHadoopで!! Hadoop / Spark Conference 2016 Future Architect Keigo Suda ローソンにおける店舗発注業務への Hadoop + Hive導入と その取り組みについて
2. 2. 本発表を通してお伝えしたいこと Enterprise 基幹領域でのHadoop活用シーンへのヒント  どういった課題をクリアするために？  どんなことを検討/対応する必要がある？ ※資料は後ほど公開致します
3. 3. 目に焼き付けておきなさい。 Hadoopを使うってそういうことよ (綺麗なことばかりじゃないのよ)
4. 4. 自己紹介 ＊ 須田 桂伍(2012年入社) ＊ Technology Innovation Group シニアコンサルタント ＊ インフラエンジニア～ソフトウェアアーキテクト ＊ 最近はビッグデータ領域(情報系～基幹系)どっぷり 最近はQiita記事に技術ネタ投稿してます 直近の生きる目標(人生のマイルストン)
5. 5. Outline Introduction Architecture Team Development Conclusion
6. 6. Our Company
7. 7. フューチャーアーキテクト株式会社 （英文表記：Future Architect, Inc.） 設 立 上 場 資 本 金 代 表 者 売 上 高 社 員 数 オフィス ： 1989年11月28日 ： 2002年6月 東証1部 ： 14億21百万円 ： 代表取締役会長 CEO 金丸 恭文 ： 連結344億24百万円、単体197億27百万円 （2014年12月期） ： 連結1,587名、単体783名 （2014年12月末日現在） ： 大崎 （本社）、大阪、鹿児島、福岡
8. 8. Introduction
9. 9. 店舗発注業務のセンター化 発注時に利用するマスタ作成をセンタ集約  店舗毎に行われていたマスタデータ作成処理を集約  店舗からはAPI経由でマスタデータを参照
10. 10. 店舗発注業務の裏側 ローソン全業務で利用されるマスタデータを 日次バッチで最新化 1 最新化された全業務マスタデータの更新差分を 各店舗へファイル連携 店舗へ更新分データのファイル連携 2 本部センター ファイル 連携基盤 ストアコンピュータ データ反映 発注端末 商品を発注 しますね 更新データ 全業務マスタデータ 日次バッチ処理 最新化 1 2 3 4 全業務マスタデータの最新化処理 連携されたファイルデータを各店舗にある ストコン内のDBへ反映する。 3 最新化されたマスタデータをもとに発注業務を実施 発注時の商品データ参照4 更新分データのDB反映処理
11. 11. 店舗発注業務の裏側 ローソン全業務で利用されるマスタデータを 日次バッチで最新化 1 最新化された全業務マスタデータの更新差分を 各店舗へファイル連携 店舗へ更新分データのファイル連携 2 本部センター ファイル 連携基盤 ストアコンピュータ データ反映 発注端末 商品を発注 しますね 更新データ 全業務マスタデータ 日次バッチ処理 最新化 1 2 3 4 全業務マスタデータの最新化処理 連携されたファイルデータを各店舗にある ストコン内のDBへ反映する。 3 最新化されたマスタデータをもとに発注業務を実施 発注時の商品データ参照4 更新分データのDB反映処理 これまでは処理負荷を 各店舗に分散していたイメージ
12. 12. 機能のセンター集約 店舗DB 発注業務 データ参照 加工処理 加工処理取込処理 取込処理 発注 端末 発注 端末 発注 端末 発注 端末 発注 端末 発注 端末 発注 端末 API API API API API API API 全店舗分の発注業務に利用する マスタデータをバッチ処理(日次)で作成 全業務マスタDBから店舗毎に必要な マスタデータの更新差分をファイルで連携 これまで店舗毎に配信されていた 全店舗分の更新差分ファイルを連携 受信用DB 公開用DB 1. 全業務マスタDBから各店舗へ更新差分ファイルを配信 2. 店舗毎にDBへ差分反映後、発注利用マスタデータを作成 3. 作成されたマスタデータは発注業務時に発注端末から参照 1. 全業務マスタDBから全店舗分の更新差分ファイルを配信 2. 受信用DBへ差分反映後、全店舗分の発注利用マスタデータを作成 3. 作成されたマスタデータはREST APIで公開し、発注端末より参照 データ参照 発注業務 Before After
13. 13. しかしその壁も高い・・・ 店舗数増加への考慮 ピーク時の処理多重度 限られたバッチウィンドウ膨大なレコード件数
14. 14. 18 20% 80% 全店舗分の処理ピークが重なる
15. 15. 19 発注商品マスタ ～10億レコード PLUマスタ ～7億レコード 商品マスタ ～5億 約70マスタテーブル(数十億レコード)
16. 16. ～1.5時間 店舗へのデータ公開バッチ処理開始 約4時間 リラン
17. 17. Distributed Architecture?
18. 18. Get Really Excited @ Midnight
19. 19. Volume Complexity Small Medium ~ Specially Complex Simple Complex ~ Enterprise Web Complex Business Logic データ観点でざくっと考えてみる(私見) Very Large
20. 20. Contains Business Logic… Much Various
21. 21. データ観点でざくっと考えてみる(私見) Volume Complexity Very Large Specially Complex Simple Complex ~Complex Business Logic Large Web
22. 22. 機能のセンター集約 店舗DB 発注業務 データ参照 加工処理 加工処理取込処理 取込処理 発注 端末 発注 端末 発注 端末 発注 端末 発注 端末 発注 端末 発注 端末 API API API API API API API 全店舗分の発注業務に利用する マスタデータをバッチ処理(日次)で作成 全業務マスタDBから店舗毎に必要な マスタデータの更新差分をファイルで連携 これまで店舗毎に配信されていた 全店舗分の更新差分ファイルを連携 受信用DB 公開用DB 1. 全業務マスタDBから各店舗へ更新差分ファイルを配信 2. 店舗毎にDBへ差分反映後、発注利用マスタデータを作成 3. 作成されたマスタデータは発注業務時に発注端末から参照 1. 全業務マスタDBから全店舗分の更新差分ファイルを配信 2. 受信用DBへ差分反映後、全店舗分の発注利用マスタデータを作成 3. 作成されたマスタデータはREST APIで公開し、発注端末より参照 データ参照 発注業務 Before After
23. 23. 候補サービス EMR Redshift RDS (AmazonEMR)
24. 24. アーキテクチャ案 WITH EMR WITH Redshift WITH RDS 取込フェーズ 加工フェーズ 参照フェーズ Data Imort Data Export SQL Batch MapReduce Storede Procedure & SQL Batch Data Imort Data Export
25. 25. ざっと比較してみる EMR 分散処理による高スループット アーキテクチャ Redshift RDS(MySQL) ノード追加によるリソース拡張 豊富なHadoopエコシステム システム拡張性 耐障害性 (ノード障害時) 処理特性 費用調整 コアノード障害ならば処理継続可能 分散処理による高スループット アーキテクチャ ノード追加によるリソース拡張 同時実行クエリ数の制約 コスト面で大量ノードで組めないので 1台失った時のインパクトでかい 更新処理がマスタサーバに集中 リードレプリカにより参照処理のみ スケール可能 マスター障害時はスレーブのマス タ昇格まで処理受付不可 コアノードのインスタンスタイプが 豊富&台数による微調整が可能 インスタンスタイプが少ない&台数に よる微調整が難しい そもそも参照しかスケールしないし な・・・
26. 26. ざっと比較してみる EMR 分散処理による高スループット アーキテクチャ Redshift RDS(MySQL) ノード追加によるリソース拡張 豊富なHadoopエコシステム システム拡張性 耐障害性 (ノード障害時) 処理特性 費用調整 コアノード障害ならば処理継続可能 分散処理による高スループット アーキテクチャ ノード追加によるリソース拡張 同時実行クエリ数の制約 更新処理がマスタサーバに集中 リードレプリカにより参照処理のみ スケール可能 マスター障害時はスレーブのマス タ昇格まで処理受付不可 コアノードのインスタンスタイプが 豊富&台数による微調整が可能 インスタンスタイプが少ない&台数に よる微調整が難しい そもそも参照しかスケールしないし な・・・ コスト面で大量ノードで組めないので 1台失った時のインパクトでかい
27. 27. やってみた
28. 28. 36 20% 80% 全店舗分の処理ピークが重なる
29. 29. 37 発注商品マスタ ～10億レコード PLUマスタ ～7億レコード 商品マスタ ～5億 約70マスタテーブル(数十億レコード)
30. 30. やってみた クラスタへのデータロード マスタデータ作成 インポート (全件) SQLバッチ(HiveQL) クラスタからのデータオフロード 平均：約60分 平均：約16分平均：約16分 平均：約90分 コアノード：~30台 エクスポート (全件)
31. 31. やってみた
32. 32. Architecture Overview
33. 33. アーキテクチャ全体像 全業務 マスタDB EMRクラスタ受信用DB ファイル連携用 バケット ファイル取込 サーバ SQLバッチ(HiveQL) 公開用DB APIサーバ 過去データ蓄積用 バケット アップロード 画像データ REST API ・・・ バイナリ配置用 バケット バイナリデータはS3パスを 返却し直接取得させる 発注端末 発注端末
34. 34. 3フェーズアーキテクチャ EMRはあくまで処理エンジン!! 得意な処理に専念させるための役割分担と機能配置 データ永続化層 データ整合性の担保 前処理の実施 データは永続化させない データ加工に専念 データ永続化層 データ公開/参照 受信用DB 公開用DBEMRクラスタ
35. 35. Processing
36. 36. アーキテクチャ全体像 全業務 マスタDB EMRクラスタ受信用DB ファイル連携用 バケット ファイル取込 サーバ SQLバッチ(HiveQL) 公開用DB APIサーバ 過去データ蓄積用 バケット アップロード 画像データ REST API ・・・ バイナリ配置用 バケット バイナリデータはS3パスを 返却し直接取得させる 発注端末 発注端末
37. 37. 加工処理の設計ポイント クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー
38. 38. 46 20% 80% 全店舗分の処理ピークが重なる クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー
39. 39. 47 20% 80% 全店舗分の処理ピークが重なる ピーク時用クラスタ 常時用クラスタ クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー
40. 40. クラスタ構成 常時処理 ピーク時処理 UPSERT INSERT クラスタ起動 クラスタ停止 対象テーブルを 差分更新 対象テーブルを 洗い替え(日付断面) クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー 受信用DB 公開用DBEMRクラスタ受信用DB 公開用DB EMRクラスタ
41. 41. 49 20% 80% 全店舗分の処理ピークが重なる ピーク時用クラスタ 常時用クラスタ クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー
42. 42. 様々な更新処理 更新サーバ 常時用クラスタ テーブル全体の部分 更新が必要な処理を担当 ピンポイントな 更新処理を担当 対象データ種の ファイルが到着/反映 クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー 公開用DB 受信用DB より速い反映が必要なデータ更新を担当
43. 43. 処理の分散設計 マスタ作成の処理粒度をどう調整するか どの粒度でマスタ作成処理(HiveQL)を並列に走らせるか 店舗毎に いっぺんにドーン 複数店舗をまとまりにして いっぺんにドーン 全店舗分を いっぺんにドーン ・・・ ・・・ クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー
44. 44. 処理の分散設計 店舗毎に いっぺんにドーン 複数店舗をまとまりにして いっぺんにドーン 全店舗分を いっぺんにドーン ・・・ ・・・ リソース不足 リソース不足 スループット抜群 クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー マスタ作成の処理粒度をどう調整するか どの粒度でマスタ作成処理(HiveQL)を並列に走らせるか
45. 45. 処理の分散設計 マスタA 分割後 マスタA 分割後 マスタA 分割後 マスタA ・・・ マスタB 分割後 マスタB 分割後 マスタB 分割後 マスタB 発注商品 マスタ 発注商品 マスタ 発注商品 マスタ 発注商品 マスタ マスタA マスタB ・・・・・・ SQL SQL SQL SQL SQL SQL 発注商品 マスタ 発注商品 マスタ 店舗コードを もとにハッシュ分散 500店舗単位で 分割され後続に続く クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー ・・・ ・・・ 全店舗分 500店舗単位 公開用DBEMRクラスタ受信用DB
46. 46. 店舗コードによる振分&パーティショニング ・・・ 500店舗毎に36分割 ハッシュ分散UDF クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー
47. 47. 店舗コードによる振分&パーティショニング ・・・ ハッシュ分散UDF 店舗コードでのパーティショニング (Dynamic Partitioning) クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー 500店舗毎に36分割 1つのテーブルにハッシュで散った 複数店舗分のデータが入っている 結合時には必ず店舗コードが必要
48. 48. 処理リラン インポート (全件) SQLバッチ(HiveQL) エクスポート (全件) リトライ/リカバリ リトライ/リカバリ リトライ/リカバリ ・・・ ワーク1 ワークN アウトプットインプット HiveQL 各処理単位で冪等にさせる マスタ作成処理も割り切って頭からリカバリできる設計 リトライ/リカバリ クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー 公開用DB受信用DB 1マスタ作成処理=1SQLファイル 中間ワークの状態管理はしない
49. 49. ワークフロー 処理命令はSDK経由で実行 EMRのStepではあくまでクラスタのプロビジョニング(Chefで実行)にのみに特化 コア マスター ・・・ 処理実行 スクリプト HiveQL 実行スクリプト HiveQL ワークフローサーバ コア コア コア SDK hive -f ${HIVEQL_FILE} ¥ --hivevar PG_ID=${PG_ID} ¥ --hivevar VERSION_YMD=${VERSION_YMD} ¥ --hivevar TEMPO_GROUP_CD=${TEMPO_GROUP_CD} ¥ >> ${LOG_FILE} 2>1 クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー
50. 50. おまけ：Sqoopではまった話 MySQLへのダイレクトエクスポートで日本語が文字化け クラスタ構成 様々な更新処理 処理の分散設計 処理リラン ワークフロー こらっ(^ ^)
51. 51. Team Development
52. 52. いつも通りの開発を!! 開発者にミドルウェア(Hadoop)の存在を意識させない仕組みづくり チーム開発ですっごく考えたこと どう品質をどう担保するか どう開発生産性をあげるか ＊ RDBでの開発に慣れたエンジニアでもいつも通りの開発ができる ＊ Hadoop/Hiveのクセを意識せずに開発ができる ＊ HiveQLの品質担保をいかに効率的に実施していくか ＊ Hiveのチェック制約の弱さをどのようにカバーするか
53. 53. チーム開発の全体像 起動時に開発DB からデータをステップ でインポート コーディングはHue エディタにて実施 HiveQLは単体テスト &回帰テストを実施 コーディング規約をも とした開発/レビュー 開発者
54. 54. チーム開発の全体像 起動時に開発DB からデータをステップ でインポート コーディングはHue エディタにて実施 HiveQLは単体テスト &回帰テストを実施 コーディング規約をも とした開発/レビュー 開発者
55. 55. Hiveでのコーディング MapReduceを意識させない規約づくり 開発者間の品質のばらつきを押さえるべく、ポイントは規約化
56. 56. HiveのユニットテストとCI Hiveだってしっかりテストしなきゃ!! HiveQL Test PG Input Data Output Data 回 帰開 発 日次で定期実行 エクセルでテストデータを 管理しながらのコーディング Hiveのチェック制約機能の弱さを頻繁なテストでフォロー
57. 57. Hiveリソースによる区分・定数管理 区分値/定数管理もHiveで!! 設計書を正とした管理(納品資料駆動開発!!) 区分/定数管理表 hiverc HiveQL
58. 58. パラメータも同様に管理 区分/定数管理表 hiverc Hiveパラメータ&UDF登録もエクセルで! 下回りの設定も設計書を正とした管理(Infrastructure as 納品資料!!)
59. 59. Need More Consideration
60. 60. 今後より検討が必要なポイント クラスタ起動 Blue Green クラスタのメンテをどうするか 発注商品マスタ 作成ジョブ 優先的に処理をさせたい リソーススケジューリングどうしよ EMRのレイヤでどう対応できるかがポイント クラスタのメンテや業務の重要度に応じたリソーススケジューリング
61. 61. Conclusion
62. 62. まとめ：基幹領域の適用シーンをもう一度考える  基幹領域だからといってHadoopを避ける理由はない(選択肢はRDBだけじゃない)  全てをHadoopで置き換えるのではなく、まずは重たいバッチ処理を部分的に切り出すよ うなはじめ方でノウハウをためるのがいいかも  Hadoop(HDFS)をベースとしてエコシステムは進化しているので、導入したHadoop基 盤をベースに様々なワークロードに対応可能 Enterprise