ブログトップ 記事一覧 ログイン 無料ブログ開設

wyukawa’s blog

2017-02-22

例外処理について個人的に思うことを書いてみる

Javaの検査例外の仕組みは理解はできるけど、結果的にはあまりうまくいかなかったかなというのが個人的な見解です。理由は例外をcatchさせても無視されることが多いから。

下記の本にもそれに近い見解が述べられていた気がするけど忘れた。

Java: The Good Parts

Java: The Good Parts

僕がSIerにいた頃は、開発者に例外をcatchさせてはいけないと言われたものでした。

共通チームが共通部品やフレームワークを整備して、他チームがそれを使って開発することが多いわけですが、その場合に個々の開発者が例外をcatchする必要がないように整備するのが一般的でした。

例えばStruts 1のActionのexecuteを個々の開発者は実装せず、Actionは自動生成してLogicクラスに切り出したものを実装するという感じです。例えが古い。。。

今思い返してもその方針自体は妥当だなと思ってます。

Javaの場合は検査例外をcatchしても実行時例外にラップしてthrowすることが多く、ボイラープレートなコードになりがちだし。

僕は以下のようなコードをよく書いてます。

try {
	...
} catch (IOException e) {
    throw new RuntimeException(e);
}

例外をcatchしても処理を続行したい場合ってそんなに無いと思うんですよね。たいていはその場でストップして良いのではという。

変にcatchさせると下記のようのあまりよろしくないコードになりがちです。

例えば下記のようなパターンです。


例外を完全に無視しているパターン

try {
	...
} catch (IOException e) {
    
}

さすがにこういうコードはそんなに見ません。

静的解析にも引っかかるだろうし。

唯一これが許されるのは、大量データを扱う処理で下手にロギングするとディスクを圧迫してしまうケースです。


例外をロギングしているけどstacktraceを捨てているパターン

import org.apache.log4j.Logger;
...
private static Logger logger = LoggerFactory.getLogger(Hoge.class);
...
try {
	...
} catch (IOException e) {
    logger.error(e);
    ret.put("error", e.getMessage());
}

APIサーバー実装する場合にユーザには例外のメッセージだけJSONで見せて、詳細のstacktraceは別途ロギングするパターンはよくありますよね。一見良さそうに見えて、stacktraceがロギングされてません。

というのに最近Azkabanで遭遇してpull requestしました。

https://github.com/azkaban/azkaban/pull/905

正しくはlogger.error(e.getMessage(), e);を使うこと。というかlog4jだとコンパイルではじけないからslf4j使うほうが良いんだろうな。


検査例外が無いPythonやRubyだったらこういうこと起きないんだろうなと思いきや、例外をexcept, rescueして元のstacktraceが消えているコードを見ることがあるので検査例外の問題ではないのかもと最近は思い始めております。

2017-02-20

高知龍馬マラソンに行ってきた

結果はグロスタイムが4時間1分40秒で、ネットタイムが3時間58分6秒。

もっと余裕でサブ4いけるかと思ったけどそんなことはなかった。。。

大会自体はすごく良かったです。荷物受け渡しに遅延もなく、帰りのシャトルバスもそんなに待たずにスムーズに乗れました。応援もいっぱいあったし、天気もよく、海沿いの景色、特に目玉の浦戸大橋からの眺めは抜群でした。

ただ参加者は約1万人いてその割に走路がちょっと狭かった気がしました。まあこの辺は人気が出て参加者が増える大会の常な気がします。

食べたのはカツオ、鍋焼きラーメンです。

高知は城があって路面電車があったので、愛媛マラソンで行った松山と似てる気がしました。

まあそんな感じです。

2017-02-12

最近は使っているミドルウェアのバージョンアップ作業をしていた

題記の通りです。

例えばElasticsearchなら2.4 -> 5.0.1 -> 5.2とバージョンアップした。

Elasticsearch 2.4から5.0.1にアップグレードしていろいろはまった - wyukawa’s blog

Elasticsearch, Kibanaを5.0.1から5.2にアップグレードした - wyukawa’s blog

HadoopならHDP2.1から2.5.3にバージョンアップした。

HDP2.1からHDP2.5.3へアップグレードした - wyukawa’s blog

そのついでにAzkabanも3.1.0から3.15.0-1-g77411d7に上げたらH2DBがぶっ壊れたので、soloをやめてwebとexecutorを両方動かしてMySQLを使うように変更しました。

azkaban-solo-server-3.15.0-1-g77411d7を使っていたらH2DBがぶっ壊れた - wyukawa’s blog

これ以外にもPrestoは新しいバージョンが出ればすぐに追随してます。


この手のバージョンアップ作業って別にやらなくてもすぐ困るわけじゃないし、新機能がすぐ必要というわけでもないので、滞りがちです。重要だけど緊急ではない仕事の典型例です。逆に問い合わせ対応とかが緊急だけどそんなに重要ではない仕事の例。

まあでもやらないと徐々に辛くなるし、バージョンアップ後の新しいのを触ると古いのが相当色褪せて見えます。新しいiPhoneを2年ぶりとかに買い換えると味わうあの感じと似てます。

それに古いバージョン使い続けてると、新しいバージョンだと治っているバグを踏んだり、新機能が使えなくて困る時がいずれ来ます。すぐには来ないけどいずれ来ます。そうなったときに困らない程度にバージョンアップ作業をするのが良いと思います。


バージョンアップはPrestoのように簡単なものもあればHadoopのように大変なものもあります。Hadoopの場合はマシンの保守切れが近いとかの外部的要因があるとバージョンアップに踏切やすいかと思います。マシンを新しくすると当然ながらハードの性能も上がっていますし、OSを新しくする良い機会でもあります。

バージョンアップを誰がやるといいかというと、やっぱり最初にそのシステムを構築した人がやるのがいいと思います。そのシステムに依存するものは何があるかというのは新しく入ってきた人だとわかりづらいからね。まあノウハウの共有という意味では一緒にやるのがベストかも。

それに最初にシステム構築した人がバージョンアップ作業をやって何かぶっ壊した方が新しい人が何かぶっ壊すよりいい。

新しい人が既存の管理者の反対を押し切ってバージョンアップを敢行して、何かぶっ壊したら空気悪くなること間違いなし。さすがにそんな現場ないと思いますけど、既存の人が率先して新しいものを取り込んだいく姿勢を見せた方が周りに良い影響があると思ってます。

新しく入ってきた人だってレガシーなもの触りたくなりだろうしね。

まあそんな気持ちでバージョンアップ作業してました。

2017-02-10

Elasticsearch, Kibanaを5.0.1から5.2にアップグレードした

題記の通りです。

リリースブログはこちら

Elasticsearch 5.2.0 released | Elastic

Kibana 5.2.0 released | Elastic


Elasticsearchは下記手順でアップグレードした。

Rolling upgrades | Elasticsearch Reference [5.2] | Elastic

アップグレード前にElasticsearchへのデータ流入を止めてから作業した。

アップグレード後に順調にunassigned shardの数が減っているのはcerebroで確認してたんだけど、数が800ぐらいになってから減り方のスピードが落ちたので、データ流入を再開したけど特に問題はなかった。

Cluster Allocation Explain APIなるものが追加されてshardのallocation状況が見れるようになった。

Cluster Allocation Explain API | Elasticsearch Reference [5.2] | Elastic


Kibanaはtar ballを入れ替えてアップグレードした。

公式手順はこちら

Standard Upgrade | Kibana User Guide [5.2] | Elastic

作業で特に問題はなかったけど、After installation on Kibana 4.2.0 the page is blank ? Issue #12 ? elastic/timelion ? GitHubは解決せず。

あとThere are too many series defined.が出たグラフもあった。期間をしぼったら解消したけど。

現象としては下記に近い。histogram使ってないけど。

Date histogram with more than 25 aggregations not getting displayed in Kibana 5.2 ? Issue #10132 ? elastic/kibana ? GitHub


またうちの環境では古いインデックスの削除にcuratorを使っているけど、4.2.4だと下記のエラーがでた。

Unable to create client connection to Elasticsearch. Error: Elasticsearch version 5.2.0 incompatible with this version of Curator (5.2.0)

最新の4.2.6ならElasticsearch 5.2に対応しているのでアップグレードする必要があった。

Releases ? elastic/curator ? GitHub

そんな感じです。

2017-02-05

こんなHadoop本が読みたい

wyukawa’s tumblr, descicoさんとHadoopについて話しましたGuest descicoShow...でも少し話したけど、日本語で読めるHadoop本が古くなっていて今だとちょっと勉強しづらい状況です。

なので、僕だったら、下記のような目次の「はじめてのHadoop」を読みたいので、コミッタがたくさんいるNTT関係者が書いてくれないかなあと思ってたりします。チラチラ。

なおこの目次は「tagomorisが騙る はじめてのHadoop」 - たごもりすメモをベースにしました。

分析基盤で使うことにしてPig, HBaseは無しという前提で書きました。

  • Hadoopの基礎
  • HDFS
  • YARN
    • MapReduce
    • Tez
    • Timeline server
    • スケジューラ
  • 設計
    • データ量の見積もり
    • データ圧縮
    • ファイルフォーマット(RCFile, Parquet, ORC)
    • ハードウェア選定
      • CPU、メモリ
      • ノードあたりのHDD台数、ディスクの選択
    • ノード数
    • ディストリビューション選定(Apache Hadoop or CDH or HDP)
      • サブスクリプション購入という選択肢ももちろんあり。
    • セキュリティ(RangerとかKnoxとか)
  • セットアップ
    • Cloudera Manager or Ambari or 自前インストール(Ansible or Chef)
    • kernelパラーメーターの確認(THP無効化とか)
    • Hadoopの設定変更(メモリとか)
    • NameNode HA
    • Resource Manager HA
  • データ投入
    • hadoop fs -put
    • WebHDFS
    • DistCp
  • Hive
    • インストール
    • ジョブ実行
    • HiveServer2経由でのクエリ実行、結果取得
    • 外部テーブル
  • Sqoop
  • Fluentd
    • fluent-plugin-webhdfsを使ってappendをオンにしたときとオフにしたときのメリット、デメリットとか
  • SQL on Hadoop(Impala or Presto or LLAP)
  • 運用
    • モニタリング
      • さすがに今時Gangliaじゃないよね
    • 監視
      • さすがに今時Nagiosじゃないよね
    • Hadoop, Hiveの設定変更
    • ノードの追加
    • DataNode障害時の対応
    • NodeManager障害時の対応
    • NameNode障害時の対応
    • Resource Manager障害時の対応
    • HiveServer2障害時の対応
    • 困った時の対応方法
    • Hadoopのバージョンアップ
  • その他
    • 情報収集方法(Hadoopソースコードリーディングに参加するとか)