Upload
kinebuchitomo
View
658
Download
4
Embed Size (px)
Citation preview
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