A S A K U S Aバッチの

運用を支える技術

健全な睡眠のために

発表者

• 名前: 杵渕 朋彦 (きねぶち ともひこ)

• 所属: 株式会社ノーチラス・テクノロジーズ

• テーマ:「ASAKUSA バッチの運用とそれに関わる技術」

• とある ASAKUSA バッチの CI 、運用、運用で使ったツールの開発の経験に基づいて

理想の運用「連絡用携帯 ? あぁ一度も呼び出されたことがないから会社に置きっぱなしさ」

現実の運用

• まずい、今日の昼までにこのバッチ正常終了させないと!

• どの範囲のデータがぶっ壊れてるのか分からない……。

• なんでここの値がログに出てないんだ!? ここのロギング処理書いたの誰だ。俺だ。

• (注。全て架空の台詞です。)

• Asakusa Framework を使っていても、トラブル対応の考え方は他のバッチと変わらない

トラブルが起きたときにやること

• 現状調査・原因究明

• 許される時間リソース (=解決の期限) を考える

• 対応策検討

• 何の解決を優先するのか?

• バッチ再リリース? バッチ再実行? データパッチが必要?

何はともあれまずは調査

• どこでどんなエラーが起きたのか?

• 結果は出力されたのか?

• 出力された結果は正しいのか?

ではトラブルに

どう備えるのか ?

トラブルはどこから起きるか ?

• 環境要因

• 想定していなかったデータ

• バッチのバグ

• 想定内 (だったはず) のデータで動かない

• ⇒ トラブルの原因を潰す手段を見ていきましょう

• とある案件を例に見ていきます

• Asakusa Framework 特有の話も交じえながら

• 処理内容「お客様環境のDBからデータを取得し、AWS 上でバッチを動かし、処理後DBに戻す」

アーキテクチャ

(補足 )

• WindGate

• RDBMS やローカルファイルと Hadoop の間のデータ転送を行うコンポーネント

• RDBMS とは JDBC 接続、リモートの Hadoop とは

SSH 接続を張る

起きた問題

• 「WindGate → EC2 クラスタ」の SSH 接続の部分でトラブルがよく起きた

• ここの接続で1回でも切断や通信失敗が起きると、即バッチ異常終了

「運用のために」 I S S U Eを上げる

• 対処: WindGateの設定項目を増やしてもらう

• 再接続する回数を設定する項目はあったものの、すぐに再接続するためあまり意味が無かった

• 再接続の間隔を設定可能に (Issue #246: https://github.com/

asakusafw/asakusafw/issues/246)

• Asakusa Framework は GitHub で Issue を受け付けている。使っている人がどんどん Issue を投げよう。ML もあるよ

• https://groups.google.com/a/asakusafw.com/forum/#!forum/users

まだ運用上の問題が… …

• バッチの再実行に問題

• DB アクセスから再実行しないといけない = お客様環境の DB に余計な負荷が掛かる

• EC2 クラスタの起動に失敗する問題

• 自作のクラスタ管理ツールで起動処理していたが、けっこう実装が複雑で面倒

「運用のための」アーキテクチャ再設計

• バッチ再実行の問題

• データ連携処理の中継地点として S3 を利用することで解決

• S3 へのアップロードが完了したところから再実行可能

• クラスタの起動に失敗する問題

• 自作のクラスタ管理ツールで起動 → EMR を利用

• EMR で Asakusa バッチを動かす方法は以下を参照

http://asakusafw.s3.amazonaws.com/documents/sandbox/ja/html/administration/asakusa-on-emr.html

改善後のアーキテクチャ

新アーキテクチャの特徴

• データ転送のネットワーク構成が変わった

• 一番不安定だった「お客様環境ーAWS」間の接続時間を短縮、トラブルが起きる頻度が減った

• S3 から再実行できる

• S3 へのデータアップロードが完了していれば、AWS 側の操作だけで再実行が可能

• 再度、DB にアクセスしなくて良い。お客様の DB に不要に負荷を掛けないために重要なこと

新アーキテクチャの特徴・その 2

• EMR の API からクラスタを起動

• サービスの使用でツールの保守負荷が下がる

• バッチのリリースが簡単

• EMR に変えたことで、S3 へのアップロードだけで済む

• 慌てやすいトラブル後の再リリース作業では、手順がシンプルなのは重要!!

アーキテクチャについて詳しくは

• ※この資料の図は処理の流れを省いて、データの流れだけを描いてある

• Asakusa Framework でのアーキテクチャの詳細は以下を参照

• 公式ドキュメント「運用環境の整備」(http://

asakusafw.s3.amazonaws.com/documents/latest/release/ja/html/administration/index.html)

• Advent Calendar (http://www.adventar.org/calendars/200) のペンギンアイコンの記事

「運用のための」ログ出力

• パッと見てどこで処理が失敗したか分かるように

• トップレベルのスクリプトが、個々の処理の結果をログに出力

• 異常終了したときは、ログファイルの内容をメールで送信 (SES

を利用)

• (補足) SES は AWS のメール送信サービス

• EMR 上に出る YAESS のログは S3 にアップロード

• (補足) YAESS: Asakusa バッチを実行するためのコンポーネント

「運用のための」ログ出力 ( A W S編 )

• AWS のログは以下の情報 (AmazonServiceException から取得できる) を出力

• ErrorCode

• Message

• RequestId

• StatusCode

• ⇒ サポートへの問い合わせで使用

「運用のために」ステージング環境整備

• 本番環境で動く保証をするには、通常ステージング環境を用意する

• 本番環境が EMR なので、ステージング環境も EMR で……

• と言いたいところだが、毎晩 EMR を起動するのはコストがかさむ……

• ⇒ Hadoop のローカルモードで EMR の模倣

• ちゃんとしたステージングとは言い難いが EMR を起動するための

shell script も実行して試験できるのが利点

「運用のために」テストをする

• TestDriver を使用

• 演算子、フローパート、ジョブフロー、バッチ単位で入力データに対する出力データの比較試験

• JUnit などで実行

• 全部のテストを開発環境で行うのが無理な場合は、テストサーバで動かす

• 詳細は公式ドキュメント「アプリケーションのテスト - TestDriver」(http://asakusafw.s3.amazonaws.com/documents/latest/release/ja/html/testing/index.html) を参照

「運用のために」C Iを回す

• テスト (単体テスト、システムテスト) 用の環境を用意

• ローカルモードでいいので Hadoop 環境を用意する

• 単体テスト→全テストケースを毎晩流す

• システムテスト→ビルドからデプロイ、バッチ実行まで通しで毎晩流す

• リリース後にバグが発覚したときの修正確認の高速化

「運用のために」設計・実装する

• Asakusa バッチ内部で実行時例外が起きるとバッチ全体が異常終了

• 例外を使わずに、エラーデータを出力するためのフローを設計する

• できるだけ実行時例外を発生させないように実装する

• 実行時例外 (= 値に由来する例外) の例

• 例1. NullPointerException: Option 系のオブジェクトで null

チェックせずに get メソッドを呼ぶ

• 例2. ArithmeticException: 割合を算出するときなどの 0 割り

某地獄のC T Oがどこかで言ってた… …

•「人は安眠のためにお金を払う」

• 「Asakusa バッチの運用を支える技術」とは「私の安眠を支える技術」

全ては運用 (安眠 ) のために

• Issue 登録、ML で報告・質問

• アーキテクチャ

• ログ出力

• 単体テスト・システムテスト

• CI

• 実装

画像を提供いただいたサイト

• GATAG http://free-illustrations.gatag.net

• CC BY ライセンスの画像

• P.8 考える人 著作者「avaxhome.ws」様

• P.24 チェックリスト 著作者「playground」様

• P.25 サイクル 著作者「freedesignfile.com」様

• その他の画像は Public Domain