Hadoopによるバッチ処理の導入 on AWS	




                                                                                                             2011/6/22
                                                                                  株式会社ノーチラス・テクノロジーズ	
                                                                                    http://www.nautilus-technologies.com/
                                                                                  mailto:contact@nautilus-technologies.com
                                                                                                         Tel: 03-6712-0636


              Copyright © 2011 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                        Proprietary & Confidential
会社紹介  2012年10月設立	
            ノーチラス・テクノロジーズ	
  
              –  消費財・流通系のミドルウェアの開発・販売・コンサル・構築	
  
                    先端技術によるソリューションをエンタープライズ・システムへ適用している	
  
                    業務系SI/コンサル〜守備範囲は流通・製造・サービス	
  


             –    Asakusa	
  Framework	
  
                      Hadoopを基幹バッチ処理に適用するためのアプリケーションフレームワークとして、
                       Asakusa	
  Frameworkを開発し、OSSとして公開中。	
  
                     –    Asakusa	
  Frameworkを利用することで、今まで敷居の高かった分散環境の、エンタープライズへの
                          適用が可能。	
  


             –    流通BMS事業     	
                     消費財流通のEDI標準であるBMS準拠のB2B-­‐ミドルウェアを提供	
  
                     –    単なるデータ交換ではなく、より生産性の高い情報共有の仕組みを提供することにより、企業間
                          取引のみならず企業内部での生産効率性に秀でるソリューションを提供している                                         	



                                   Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                                             Proprietary & Confidential                             1
そもそも何が問題
             なのか?	
             Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                       Proprietary & Confidential                        2
そもそも何が問題なのか	
            既存のバッチ処理は一向に改善されていない	
  
              –  汎用機からオープン系のレガシー・マイグレーションは、フロントエンドのオンライン処理に
                 とどまり、バックエンドのバッチ処理は、十数年来にわたり放置されている。	
  
              –  結果として	
  
                    バッチ処理の負荷に対する対策に打つ手がなくなりつつある。	
  
                    バッチ処理時間の突抜けによる、「直接損害」の発生が大規模障害に発展することも
                     起きるようになってしまった	
  


           バッチ速度の向上は、既存のテクノロジーでは限界がある	
  
                 分散IOを利用したHadoopでバッチ処理の高速化が可能	
  
                 従来のスーパーコンピューターの技術を利用	
  




                         Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                                   Proprietary & Confidential                        3
アンデルセン・サービス様	




                    Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                              Proprietary & Confidential                        4
アンデルセン様のケース	
            現状  	
  
             –  原材料からの製品原価計算で4時間近くかかっている。	
  
                  ビッグデータではないが、BOMの展開・原価の積上げに時間がか
                      かっていた。 	
  
                  木構造の関連を辿るのでRDBMSだと効率が悪い。 	
  


             –  課題	
  
                   原価計算のシミュレーションをかなりの頻度で行いたい	
  
                     –  現状の4時間バッチでは、その時間のバッチ・ウィンドウの確保が
                        週に2回が限界	
  
                     –  原価は想定や予算ではなく、「アクチュアルの数字」で行いたい	
  
                          実際のBOMのデータそのものを利用したい	
  




                           Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                                     Proprietary & Confidential                        5
3.11	

           Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                     Proprietary & Confidential                        6
バッチ実行時間について	
             実際の実行時間	
  
             –      Clusterの起動と停止	
                                  4時間のバッチ処理が20分で終了	
                        4分~非常に高速	
  


             –      データの送受信の転送	
  
                       5分~数G程度なので、時間はかからない→基幹系のデータの特徴	
  


             –      実際の計算	
  
                       12分~実際の計算はこの程度で終わっている。	
  

                        Clusterの起動	
       データの転送	
                   原価計算	
                データの受信	
                  Clusterの停止	



             	
  
       バッチ処理時間	
                2	
                                 12	
                                      3	
         2	
  
             	
  
             	
  

                     0	
                5	
                         10	
                         15	
                    20	
        25	
  


                                          Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                                                    Proprietary & Confidential                                                        7
Asakusa+AWS	
            AmazonVPCでHadoop基幹バッチを動かす	
  
             AmazonVPCを利用することで、特別の追加的なハードは一切不要。あたかも自社の
              ネットワークの延長上で、バッチが動いているように見える	

            アンデルセン様データセンター
                         	
                                                                           Amazon VPC
                                                                                                               	
                                                                                                     ④バッチを実行する。
                                                                                                                             ④	
   Hadoop Slave
                                                                                                                                              	

            ①本番のDBサーバーから                             ②シーケンスファイ                                        ③受信したデータを
            、原価計算に必要な情報を                               ルで転送する。                                        HDFSへ登録する。
                   取得する。

                        ①	
                        ②	
           インターネット
                                                                       	
                                              ③	
                                              バイナリファイル	
                               バイナリファイル	
                  入力ファイル	


                                              バイナリファイル	
                               バイナリファイル	
                      結果ファイル	
                        ⑥	
              DBサーバ	
         バッチサーバ	
                                                      ⑤	
        Hadoop Master


                 ⑥処理結果をDBサーバ                                                                      ⑤バッチ処理結果を圧縮し
                  ーへアップデートする。                                                                           て転送する。




                                 Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                                           Proprietary & Confidential                                                                      8
Asakusa	
            Hadoopは基本的にBIを前提の仕組みで、足りない部分が多い	
  
              –  そもそも大規模開発の手法がない	
  
              –  MRやWritableの実装が職人芸	
  
              –  テストツールが貧弱	
  
              –  運用についてはあまり考えていない	
  
              –  ちょっと人数が増えると制御不能になるのでPig・Hiveのような上位層の利用が必須になる。	
  
                    ところが・・・Hadoopでは、基幹バッチでよく使われる「非常に多種類のデータ」の「単
                     純な処理の組み合わせ」 を「複雑なフロー処理」で行う仕組みのための上位層がな
                     い。	
  
                    Pig・Hiveではちょっと無理っぽい。また、開発方法論も特にない。テスト・運用ツール
                     が不足している。	
  
                                                  JP1等の通常管理                                         Oozie
                                                                                                        	

                                                         Asakusa
                                                               	
                            Pig
                                                                                               	
            Hive
                                                                                                                	

                                                                     Hadoop Core
                                                                 Core・HDFS・MapReduce
                                                                                   	

                         Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                                   Proprietary & Confidential                                                9
Asakusa	
  DSL	
            データフローを意識したDSL	
  
              –  個々のデータが流れながら分類、変更されていく	
  
              –  データフロー形式で設計すれば実装も容易	
  

            DSLからコンパイラでMapReduceを生成	
  
              –  開発時にMapReduce自体はできるだけ意識させない	
  
              –  MapReduce特有のコードをコンパイラが自動生成	
  




                                               DSL
                                                 	
                                                   MR   	
     MR   	
  

                                             コンパイラ    	
                                              #1	
        #2	
  

              • Asakusa	
  DSL
                             	




                                  Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                                            Proprietary & Confidential                                                10
Hadoopによる基幹系バッチ処理の分散
      化はクラウドに適している
      Ø    データ量は、それほど大きく無い
      Ø    データ転送にコストがかからない
      Ø    クラウド上にデータを残さない
      Ø    インフラ構築及び運用コストが圧倒的に削減される
      Ø    グローバルレベルでDRが実現	



                 Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                           Proprietary & Confidential                        11
AWSは、真のクラウドコンピューティング
      Ø    必要な時に必要なリソース
      Ø    Pay as you go
      Ø    4時間のバッチ処理が20分	




                  Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                            Proprietary & Confidential                        12
私たちがやりたいこと

           Ø  エンタープライズシステムにイノベーションを
             提供、日本企業の競争力強化。
           Ø  次世代に強い日本を残す(大人の責任として)
           	



                 Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                           Proprietary & Confidential                        13
私たちがやりたいこと
             エンタープライズの世界で20代〜30代の
           Ø 
             若手エンジニアに輝いてもらいたい!
             (大人の責任として)




                 Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                           Proprietary & Confidential                        14
Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                     Proprietary & Confidential                        15
ありがとうございました。	
  
           	



              Copyright © 2012 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS                        Proprietary & Confidential                        16

2012年上半期 AWSパートナーアワード受賞社資料:Hadoopによるバッチ処理の導入on AWS (ノーチラス・テクノロジーズ様)

  • 1.
    Hadoopによるバッチ処理の導入 on AWS 2011/6/22 株式会社ノーチラス・テクノロジーズ http://www.nautilus-technologies.com/ mailto:contact@nautilus-technologies.com Tel: 03-6712-0636 Copyright © 2011 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential
  • 2.
    会社紹介  2012年10月設立  ノーチラス・テクノロジーズ   –  消費財・流通系のミドルウェアの開発・販売・コンサル・構築     先端技術によるソリューションをエンタープライズ・システムへ適用している     業務系SI/コンサル〜守備範囲は流通・製造・サービス   –  Asakusa  Framework     Hadoopを基幹バッチ処理に適用するためのアプリケーションフレームワークとして、 Asakusa  Frameworkを開発し、OSSとして公開中。   –  Asakusa  Frameworkを利用することで、今まで敷居の高かった分散環境の、エンタープライズへの 適用が可能。   –  流通BMS事業   消費財流通のEDI標準であるBMS準拠のB2B-­‐ミドルウェアを提供   –  単なるデータ交換ではなく、より生産性の高い情報共有の仕組みを提供することにより、企業間 取引のみならず企業内部での生産効率性に秀でるソリューションを提供している Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 1
  • 3.
    そもそも何が問題 なのか? Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 2
  • 4.
    そもそも何が問題なのか  既存のバッチ処理は一向に改善されていない   –  汎用機からオープン系のレガシー・マイグレーションは、フロントエンドのオンライン処理に とどまり、バックエンドのバッチ処理は、十数年来にわたり放置されている。   –  結果として     バッチ処理の負荷に対する対策に打つ手がなくなりつつある。     バッチ処理時間の突抜けによる、「直接損害」の発生が大規模障害に発展することも 起きるようになってしまった   バッチ速度の向上は、既存のテクノロジーでは限界がある     分散IOを利用したHadoopでバッチ処理の高速化が可能     従来のスーパーコンピューターの技術を利用   Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 3
  • 5.
    アンデルセン・サービス様 Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 4
  • 6.
    アンデルセン様のケース  現状   –  原材料からの製品原価計算で4時間近くかかっている。    ビッグデータではないが、BOMの展開・原価の積上げに時間がか かっていた。    木構造の関連を辿るのでRDBMSだと効率が悪い。   –  課題    原価計算のシミュレーションをかなりの頻度で行いたい   –  現状の4時間バッチでは、その時間のバッチ・ウィンドウの確保が 週に2回が限界   –  原価は想定や予算ではなく、「アクチュアルの数字」で行いたい    実際のBOMのデータそのものを利用したい   Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 5
  • 7.
    3.11 Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 6
  • 8.
    バッチ実行時間について   実際の実行時間   –  Clusterの起動と停止   4時間のバッチ処理が20分で終了   4分~非常に高速   –  データの送受信の転送     5分~数G程度なので、時間はかからない→基幹系のデータの特徴   –  実際の計算     12分~実際の計算はこの程度で終わっている。   Clusterの起動 データの転送 原価計算 データの受信 Clusterの停止   バッチ処理時間 2   12   3   2       0   5   10   15   20   25   Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 7
  • 9.
    Asakusa+AWS  AmazonVPCでHadoop基幹バッチを動かす     AmazonVPCを利用することで、特別の追加的なハードは一切不要。あたかも自社の ネットワークの延長上で、バッチが動いているように見える アンデルセン様データセンター Amazon VPC ④バッチを実行する。 ④ Hadoop Slave ①本番のDBサーバーから ②シーケンスファイ ③受信したデータを 、原価計算に必要な情報を ルで転送する。 HDFSへ登録する。 取得する。 ① ② インターネット ③ バイナリファイル バイナリファイル 入力ファイル バイナリファイル バイナリファイル 結果ファイル ⑥ DBサーバ バッチサーバ ⑤ Hadoop Master ⑥処理結果をDBサーバ ⑤バッチ処理結果を圧縮し ーへアップデートする。 て転送する。 Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 8
  • 10.
    Asakusa  Hadoopは基本的にBIを前提の仕組みで、足りない部分が多い   –  そもそも大規模開発の手法がない   –  MRやWritableの実装が職人芸   –  テストツールが貧弱   –  運用についてはあまり考えていない   –  ちょっと人数が増えると制御不能になるのでPig・Hiveのような上位層の利用が必須になる。     ところが・・・Hadoopでは、基幹バッチでよく使われる「非常に多種類のデータ」の「単 純な処理の組み合わせ」 を「複雑なフロー処理」で行う仕組みのための上位層がな い。     Pig・Hiveではちょっと無理っぽい。また、開発方法論も特にない。テスト・運用ツール が不足している。   JP1等の通常管理 Oozie Asakusa Pig Hive Hadoop Core Core・HDFS・MapReduce Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 9
  • 11.
    Asakusa  DSL  データフローを意識したDSL   –  個々のデータが流れながら分類、変更されていく   –  データフロー形式で設計すれば実装も容易    DSLからコンパイラでMapReduceを生成   –  開発時にMapReduce自体はできるだけ意識させない   –  MapReduce特有のコードをコンパイラが自動生成   DSL   MR   MR   コンパイラ   #1   #2   • Asakusa  DSL Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 10
  • 12.
    Hadoopによる基幹系バッチ処理の分散 化はクラウドに適している Ø  データ量は、それほど大きく無い Ø  データ転送にコストがかからない Ø  クラウド上にデータを残さない Ø  インフラ構築及び運用コストが圧倒的に削減される Ø  グローバルレベルでDRが実現 Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 11
  • 13.
    AWSは、真のクラウドコンピューティング Ø  必要な時に必要なリソース Ø  Pay as you go Ø  4時間のバッチ処理が20分 Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 12
  • 14.
    私たちがやりたいこと Ø  エンタープライズシステムにイノベーションを   提供、日本企業の競争力強化。 Ø  次世代に強い日本を残す(大人の責任として) Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 13
  • 15.
    私たちがやりたいこと エンタープライズの世界で20代〜30代の Ø    若手エンジニアに輝いてもらいたい! (大人の責任として) Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 14
  • 16.
    Copyright © 2012Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 15
  • 17.
    ありがとうございました。   Copyright © 2012 Nautilus Technologies, Inc. All rights reserved. NAUTILUS Proprietary & Confidential 16