まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:manholemap

この記事の続きです:
2016 マンホーラー実態調査

2016年にマンホールマップでもっとも人気のあったマンホール蓋をベスト10形式で紹介します。また今年新たに投稿された蓋の中で最も人気があった「新人賞」と、今年最も多くの蓋画像を投稿いただいた方「最多投稿賞」を紹介します。

集計のルールとしては 2016/Jan/01 から 2016/Dec/20 までの間に、PC およびスマホのブラウザから単独ページとしてのアクセス数を集計しています。ページビューとしての集計なので、例えば同じページの画面をリロードした場合は1回とだけカウントされます。

過去2回の結果はこちらを参照ください:
2014 マンホールマップ年間アクセス数ランキング
2015 マンホールマップ年間アクセス数ランキング


2016 最多投稿賞

今年マンホールマップに最も多くの画像を投稿いただいたユーザーに与えられる賞です。実は今年のマンホールマップに投稿された全 836 画像のうちの半分以上はなんと2名のユーザーによって提供されたものでした。感謝の限りでございます。 m(__)m

さて、そのデッドヒートを制した最多投稿賞は・・・ 42ER03 様でした。歴史的な蓋から海外蓋まで幅広く投稿いただきました。ちなみにマンホールマップ全体で現在使っているハードディスク使用量の約 5% は 42ER03 様の投稿データだったりします(笑)。

そして例年であれば1位になるレベルの投稿をいただきながら2位となったしこれんminamu4545)様。マンホールナイト8でも発表いただいた展示蓋を中心に多くの投稿をいただきました。展示蓋という新ジャンルを確立されたといってもいいと感じました。


#どうでもいいことですが、私自身はお二人に大きく離されての4位でした。来年もがんばります。


2016 新人賞

今年マンホールマップに投稿された蓋の中で、最も多くのアクセス数を記録したのは、この蓋画像でした:
市区町村投稿者画像
朝鮮民主主義人民共和国42ER03


今年の新人賞はなんとピョンヤンの蓋!撮ってよかったのか!?という疑問は置いといて、最多投稿賞も受賞された 42ER03 さんの投稿でした。 42ER03 さんは昨年のモンゴル蓋に続いて「2年連続新人賞」(!?)という偉業を達成されました。最多投稿と合わせて2冠ですね、素晴らしい! 改めておめでとうございます。


2016 年総合ランキングベスト10

さて、今年のマンホールマップアクセスランキングには大きな特徴がありました。それは「今年投稿された蓋画像のアクセス数が多かった」ことです。 例年は「その年に投稿された蓋(以下「新人蓋」)画像のアクセス数」は「以前に投稿された人気画像のアクセス数」と比べて明確に劣るという特徴があり、そのため「新人賞」という別枠を作っていたという背景もありました。投稿されたのが年の後半になるほど総アクセス数を稼ぐのが不利になるのも事実であり、現実問題として過去に新人蓋がベスト10に入ったことはありませんでした。

ところが今年はベスト10の中に3つベスト11~20の中に5つも新人蓋が入るという異常事態が起こってしまいました。来年以降の「新人賞」という枠の存在意義がなくなってしまいかねない状況です。びっくり。

そしてこの総合ランキングトップとなる MVM(Most Variable Manhole) には、上記 42ER03 様の三冠、昨年&一昨年を制したやなぽん様の三連覇もかかっています。ドキドキなランキング、まずは10位から4位まで:


順位昨年順位市区町村投稿者画像
105石川県河北郡内灘町keymoyaking


↑10位はマンホールマップでの最多「ナイスマンホ!」記録を現在も持つ石川県河北郡内灘町のかもめマンホールでした。このマンホールは唯一三年連続ベスト10入りした蓋となりました。常に安定した人気を誇る、マンホールマップを代表する蓋でもあります。


順位昨年順位市区町村投稿者画像
9-山梨県甲斐市minamu4545


↑9位は山梨県甲斐市のマスコットキャラクター「やはたいぬ」がデザインされたマンホールでした。マンホールカードのデザインとしても採用されています。アクセス数にはカードの影響もあるでしょうね。ちなみにこの蓋は新人蓋です。


順位昨年順位市区町村投稿者画像
8-大阪府吹田市mnakam2003


↑8位は大阪府吹田市の吹田サッカースタジアム周辺にあるガンバ大阪マンホールでした。吹田市といえば「太陽の塔」マンホールが有名ですが、新しい名物マンホールになりえるマンホールです。


順位昨年順位市区町村投稿者画像
7-岐阜県美濃加茂市SatoMachiya


↑7位は岐阜県美濃加茂市稲辺地区の紫陽花&カエルマンホール。紫陽花は市の花だそうで、カエルは汚水をきれいな水に「変える」意味でデザインされているとのことです。


順位昨年順位市区町村投稿者画像
62群馬県高崎市TMW_papa


↑6位は昨年2位だった群馬県高崎市の「ぐんまちゃん」マンホールでした。2年連続のベスト10入りとなり、根強い人気を感じます。存じ上げなかったのですがサッカーに力入れてるんでしょうかね??


順位昨年順位市区町村投稿者画像
5-兵庫県明石市42ER03


↑5位は兵庫県明石市に子午線マンホール。実はマンホール画像ではなくスタンプの画像なのですが・・・ まあアクセス数が多かったのは事実なのでいいとしましょうw これも新人蓋でした。


順位昨年順位市区町村投稿者画像
4-朝鮮民主主義人民共和国42ER03


↑4位は新人賞をとったピョンヤンの風景と蓋の画像でした。当たり前といえば当たり前ですが、(日本でも下水が普及していないと見つかりにくい地域がある中で)ピョンヤンにもマンホールは存在してるんですね。。その証拠とも言える貴重な画像だと思います。マンホールマップなんかで公開してていいのだろうか・・・


ではランキングトップ3の発表です。

第3位

順位昨年順位市区町村投稿者画像
31北海道岩見沢市yanapong


↑昨年の MVM だった、北海道岩見沢市(旧栗沢町)、やなぽんさん提供の「リスのクリちゃん」マンホールでした。今年は3位でしたが、2年連続トップ3を記録したのは初めてだったりします。隠れた人気蓋ですが、栗沢町が岩見沢市との統合でなくなってしまったこともあり、現在では新設されることのない、貴重なマンホールとなっています。

第2位

順位昨年順位市区町村投稿者画像
26茨城県つくば市kenitirokikuti


↑昨年も6位と人気のあった茨城県つくば市のスペースシャトルマンホールでした。コンスタントに人気の高い蓋です。背景にはつくばのシンボルでもある筑波山がそびえ、土星のようなよくわからない星(?)が描かれたマンホールです。ブラジルっぽい色合いも特徴的で、これもマンホールカード化されています。


今年のベスト10蓋は例年以上にカラー蓋が多くランキング入りしています。マンホールカードの影響もあると思いますが、マンホール観賞がより一般的に広まってきた証拠かもしれません。嬉しいことです。

そんな今年の栄えある MVM は!? 42ER03 さんの三冠と、やなぽんさんの個人3連覇の行方は果たして!!??


第1位






































順位昨年順位市区町村投稿者画像
1-東京都港区dotnsf


・・・僕が投稿したやつだ。。 (O.O;

カラー蓋でもないし、マンホールカードにも採用されてないし、デザインもアレだし、、、ちなみに知り合いの家の近くで撮影した、エバタ株式会社のインバート蓋です。なんか見たことなかったので。。

いや、あの・・・ 僕が試験的に負荷をかけたとか、そんなことはないんですが・・・ とりあえず、ごめんなさい。。。


この蓋は特別アクセスが多かった日があったわけではないのですが、夏頃に連続して何度か参照されたことが積み重なってアクセスが記録されていました:
2016122101


加えて、参照されたページを調べてみると、この蓋はスマホ版のスライドパズルでのアクセスが 47%(図の青)もありました:
2016122102


たしかにスライドパズルでは比較的難易度の高い蓋だと思いますが、誰か愛好者がいたんですかね。。:
2016122103


実は昨年の MVM もスライドパズルでアクセス数をかせいでの1位でした。スライドパズル機能は作者である僕が考えている以上に使われている機能なのかもしれません。。。ただ、それにしてもなんでこの蓋を・・・ 奥深い何かが潜んでいるのかもしれません(マンホールだけに)。


最後になりましたが、今年はマンホールカードの配布など、マンホールの認知度を広めるという意味では大きな節目となった1年であったと思います。マンホールマップのアクセス数も大きく増え、内部の話をするとサーバーにかかる負荷も大きくなっております。嬉しい悲鳴です。

来年も皆様に安心してマンホールマップを使っていただけるよう、新機能だけでなく、安定運用にも注力していこうと思っています。引き続きマンホールマップをよろしくお願いします。

そして MVM 、中の人が取っちゃってごめんなさい!でも本当はすごく嬉しいですっ!!

今年もマンホーラー実態調査の結果発表の季節がやってまいりました! 2016/Jan/01 から 2016/Dec/19 までのマンホールマップと連携した Google Analytics とアクセスログ、そして実データを使って、2016 年のマンホーラー(注 マンホールが好きな人)の実態と傾向を浮き彫りにする、というビッグデータ解析企画です。ちなみに昨年と一昨年の結果はこちらから参照ください:
 2014 マンホーラー実態調査
 2015 マンホーラー実態調査


2016 マンホールマップ利用動向

2016122002

1回のセッションでの平均ページ数は 4.69、直帰率は 53.53% 、平均セッション時間は 4 分 43 秒でした。昨年は 4.65 と 56.77%、4分22秒だったので全ての数字が改善の方向で推移しています。昨年と比較して、マンホールマップを訪れたユーザーが、より多くのページに移動して長く楽しんでいただいている、ということになります。直帰率 50% 切りも視野に入ってきました。

なお、アクセス数は非公開ですが、昨年比で倍近いページビュー数があった、ということを報告しておきます。


利用者の国、言語

今年は 62 の国/地域からマンホールマップをご利用いただきました(昨年は 65):
2016122012


国別のアクセス数1位はダントツで日本ですが、2位以下は毎年変化しています。さて 2016 年はというと・・・
2016122003


2位は UK(イギリス)からのアクセスでした。なんでだろう?ポンド安でみんな旅行してた?3位アメリカ、4位ロシアあたりは上位の常連国です。 今年目立って高かったのは8位イラク、11位タイ、14位ミャンマーあたりでしょうか。水道関係者やインフラ整備で派遣されている皆様がこれらの国々で活躍されている姿が目に浮かんできます。。



日本国内の市区町村別アクセスランキング

では日本国内の市区町村別ではどのようなランキングだったかを調べてみました:
2016122004


見やすいように日本語で表にして、昨年からの順位推移を含めてみました:
1大阪市
2横浜市
3加古川市
4港区
5新宿区
6名古屋市
7(取得不可) -
8さいたま市
9札幌市
10市川市
11(東京都)中央区
12京都市
13新潟市
14千葉市
15福岡市
16世田谷区
17渋谷区
18神戸市
19船橋市
20江東区


アクセス記録一位は大阪市の2連覇。関西マンホールサミットの影響なのでしょうか?そしていわゆる「大都市」が軒並みランクを下げる中で加古川市や船橋市、市川市といった衛星都市が順位を挙げています。マンホール界では地方分権が進んでいるようです。


利用環境

利用しているブラウザ環境を同様の表にまとめてみるとこんな感じです:
1Chrome34.26%
2Internet Explorer23.34%
3Safari17.13%
4モバイル Safari11.47%
5Edge6.18%
6FireFox4.20%
7モバイル Chrome2.74%
8(クローラーボット)0.24% -
9Opera 0.17%
10Mozilla 互換0.09%


1位は推奨環境でもある PC の Chrome、非推奨環境と明確に言っているにも関わらず2位が IE、3位は Safari、ここまでは昨年と同順位です。変わったのはその下でモバイル Safari が伸びているのは iPhone 利用者が増えていることを意味しています(逆にモバイル Chrome が落ちているので Android 利用者は減っている)。このあたりはグローバルスタンダードを逆行しています(苦笑)。また昨年は 0.55% だった Edge が FireFox を抜いている点も見逃せません。。

なお、10位の "Mozilla 互換" というのは、ネットテレビだったり、ゲーム機だったりが考えられます。まだまだ少ないのですが、いずれこういう環境も増えていくのでしょうか?テレビだと画面が広くて便利そうではありますよね。



まとめ

以上の内容から 2016 年のマンホーラーの実態は以下のようなものであったと推測されます:
・イギリスが EU から分離して、ポンド安に笑いが止まらない人がいる
・マンホーラーは昨年以上に世界中に広まっている。そして日本では地方分権が進んでいる
・マンホーラーは iPhone 派
・大阪熱い!
・Internet Explorer は不滅



さて、次回のブログでは 2016 年マンホールマップ蓋別アクセスランキングを発表します。2016年の MVM(Most Variable Manhole) の行方は!? やなぽんさん、3連覇なるか!? お楽しみに。


昨年末、マンホールマップIBM Watson の画像認識機能を組み込んだ、という記事を紹介しました:
マンホールマップに画像認識機能を組み込む

この記事を作成した当時、Visual Recognition(画像認識)の API は V2 というバージョンでしたが、その後のバージョンアップで V3 になりました。ただその時点では V2 もしばらく使えるということだったのでマンホールマップ側は放っておいたのですが、いつの間にか V2 は使えなくなっており、マンホールマップの画像認識機能が動かなくなってしまっていました(要するに僕の手抜きでした、失礼しました)。

改めて V3 に対応させようとして、上記リンク先で紹介したような手順でマンホール画像の学習をさせて・・・と思っていたら信じられないことが!!!

上記リンク先ページ内でも説明しているのですが、もともと IBM Watson の画像認識サービスでは「マンホール」を識別する機能(正確には classifier)がありませんでした。そのため(自分でカスタマイズする classifier に)「マンホール画像を学習」させて、「その上で(自分でカスタマイズした classifier を使って)マンホール識別」を行う、という手順が必要になり、その内容を紹介したのが上記リンク先ページでした。

が、今回 V3 を試してみて気付いたのは「バージョン V3 では始めからマンホールが識別できるようになっている!」ということです。要するに学習などのカスタマイズを行うまでもなく、標準機能としてマンホールが識別対象として登録されていたのでした。ワトソンに何が起こったのか・・・


・・・唯一思い当たる節があるとすれば、私ですw σ(^^; 先程から紹介しているように、V2 の頃にマンホールを学習させ、識別機能をマンホールマップに組み込みました。マンホールマップはそこそこ(苦笑)のアクセス数を誇る位置情報付きマンホール情報サイトであり、マンホール情報ページへのアクセスがある度に画像認識の識別 API が実行され、そしてその多くは「マンホール」として認識されていたはずでした。要するに「マンホール」と認識されるアクセスがワトソン側にもそこそこあったはずなのです。元々の機能ではマンホールを対象としていなかったはずなのですが、カスタマイズされた結果のマンホールがそれだけの人気があったとすると・・・ と都合よく妄想しただけですが、可能性がないとは言い切れないではないですかっ!


というわけで、現在のマンホールマップでは V3 に対応した識別機能が復活しています。そしてこのマンホール識別はワトソンの標準識別対象になっているものをそのまま使っている、ということを付け加えておきます。
2016090601


マンホールマップ(PC版)
マンホールマップ(スマホ版)


マンホール、およびマンホールマップの話です。


マンホールマップでは登録されたマンホール写真が地図上のどこにあるのか、を調べるだけでなく、どの都道府県のどの市区町村にどんなマンホールがあるか、といった逆引き(?)の検索も可能です:
http://manholemap.juge.me/mc.jsp


こういう話題の際に必ず出てくるのが「市町村合併」の話です。1995年に成立した合併特例法により、2005年から2006年にかけて市区町村の合併がピークを迎えました。俗にいう「平成の大合併」です。法律の変更によって、市になる条件が緩和された上に、財政支援策が拡充されたことで、町や村が合併して市になる(あるいは既存の市の一部として合併する)という動きが見られました。 こういった合併が行われると、合併前の(無くなってしまった)自治体のマンホールは新たに製造されることがなくなるので、「レア物」という形で、ある意味での昇格をする形になります。

↑旧埼玉県浦和市(現さいたま市)のマンホール


で、この市町村合併が行われる際には、同一の都道府県内の市町村が合併する、というのが一般的ですが、ごく稀に例外があります。つまり都道府県を越えた合併が行われることがあります。これが越境合併です。ある日を境に○○県民が住居を変えずに××県民になる、ということが発生します。

比較的最近では 2005 年2月13日、それまでは長野県木曽郡山口村と呼ばれていた地域がこの日から岐阜県中津川市に編入する形で合併が行われました。長野県がちょっとだけ小さくなり、その分岐阜県が大きくなったわけです。

なお、この直前の越境合併は1959年なので、実に46年ぶりの越境合併が行われたことになります。ちなみにこの越境合併によって、旧山口村の郵便番号と自動車のナンバープレート(の管轄支局)も中津川市のものに変わったようです。なぜか市外局番は変わらなかったらしいです。

で、そのような背景を持つ、超レアな旧山口村のマンホールがこちらです。村の木であったツバキと、同じく村の花であったムラサキツツジをあしらったデザインになっています:



財政的な理由もあって、今でも市町村合併や市政への移行は多く発生していますが、道にはその名残が残り続けるわけです。そんな歴史の道しるべという意味でもマンホールは面白いです。デザインの華やかさだけがファンの心を掴んでいるわけではない、ということを紹介したかったのでした。

先日、マンホールマップのログイン機能に障害が発生しました:

通常、マンホールマップ(PC版)のトップページにアクセスすると、画面右上には "Login with Twitter" マークが表示されます(未ログインの場合):
2015122801


で、ここをクリックして、Twitter の OAuth 認可によってマンホールマップにログインして・・・という流れでログインするのですが、ここに問題が発生していると「現在、何らかの障害によってログインできません。」というメッセージが表示されます:
2015122802


一般的には Twitter API の障害が発生していることを示すメッセージなのですが、先日マンホールマップで発生していたものは Twitter API には障害が発生していないにも関わらず、上記のようなメッセージが表示されていたのでした。 ちなみに Twitter API の稼動状態はこちらで確認できます:
API Status | Twitter Developers


さて、上記の原因はなんだったのでしょうか? ちなみにマンホールマップは Java で開発された Web アプリケーションで、この Twitter の OAuth 認可の部分は Twitter4J を使って実装しています(最新版の 4.0.4 でも、スナップショット版の 4.0.5 でも再現)。で、問題部分のコードは以下のようになっていました:
String authorizationURL = null;
try{
  Twitter twitter = new TwitterFactory().getInstance();
  twitter.setOAuthConsumer( TWITTER_CONSUMER_KEY, TWITTER_CONSUMER_SECRET );
  RequestToken requestToken = twitter.getOAuthRequestToken();  ←ここで Exception 発生

  String token = requestToken.getToken();
  String tokenSecret = requestToken.getTokenSecret();
    :
    :
}catch( Exception e ){
  e.printStackTrace();
}

リクエストトークンを取得するための Twitter.getOAuthRequestToken() メソッド実行時に Exception が発生していました。それまでに設定しているのは Twitter API の Consumer Key と Consumer Secret だけで、これは正しい値が設定できていました(というか、正しく動いていた時から何も変えてません)。 で、その下の catch 内で以下のようなスタックトレースが出力されていました:
Invalid signature on ECDH server key exchange message
Relevant discussions can be found on the Internet at:
        http://www.google.co.jp/search?q=3cc69290 or
        http://www.google.co.jp/search?q=45a986b4
TwitterException{exceptionCode=[3cc69290-45a986b4 3cc69290-45a9868a], statusCode=-1, message=null, code=-1, retryAfter=-1, rateLimitStatus=null, version=4.0.5-SNAPSHOT(build: 9b7efa6faa540a9defb3e6ba9122a356155986b1)}
        at twitter4j.HttpClientImpl.handleRequest(HttpClientImpl.java:179)
        at twitter4j.HttpClientBase.request(HttpClientBase.java:57)
        at twitter4j.HttpClientBase.post(HttpClientBase.java:86)
        at twitter4j.auth.OAuthAuthorization.getOAuthRequestToken(OAuthAuthorization.java:115)
        at twitter4j.auth.OAuthAuthorization.getOAuthRequestToken(OAuthAuthorization.java:92)
        at twitter4j.TwitterBaseImpl.getOAuthRequestToken(TwitterBaseImpl.java:292)
        at twitter4j.TwitterBaseImpl.getOAuthRequestToken(TwitterBaseImpl.java:287)
        at me.juge.geoimgweb.AppInfo.GetAuthorizationURLTwitter(AppInfo.java:361)
        at me.juge.geoimgweb.AppInfo.GetAuthorizationURL(AppInfo.java:350)
        at org.apache.jsp.stats_jsp._jspService(stats_jsp.java:928)
        at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:377)
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:122)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
        at java.lang.Thread.run(Thread.java:745)
Caused by: javax.net.ssl.SSLKeyException: Invalid signature on ECDH server key exchange message
        at sun.security.ssl.HandshakeMessage$ECDH_ServerKeyExchange.(HandshakeMessage.java:1098)
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:278)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:913)
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:849)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1035)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
        at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1093)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
        at twitter4j.HttpClientImpl.handleRequest(HttpClientImpl.java:137)
        ... 30 more


問題の getRequestOAuthToken() を実行した時に "Invalid signature on ECDH server key exchange message" というエラーメッセージが出力されています。何コレ?"Invalid signature" って言われても、この時点ではこちらは Key と Secret 以外何も指定してないので間違えているとは思えないけど・・・??

しつこいようですが、今までは何の問題もなく動いていたコードが、ある時を境に急にこのような挙動になってしまいました。となると、Java ソースコードに直接の原因があるとは考えにくい・・・


しかもこの問題、何が厄介かというと、デバッグしようとしてローカルの Eclipse 内で動かすと、このエラーも Exception も発生しないのです。ちゃんと動いてしまいます。更に言うと、別のサーバー内に同様の Java + Tomcat 環境を作って、同じ war をデプロイして実行しても発生しない。要はこの本番サーバーだけで発生するエラーだったのです。。 となると環境依存か、原因特定は更に厄介だぞ・・・

とりあえず緊急でサーバーを1つ作り、そちらに Java と Tomcat を導入し、アプリの war をデプロイ、したら動きました。なので、応急処置としてはこれでなんとかなります。この応急処置サーバーで運用を続けながら原因追求と解決を続けます。 ああ、クラウドってこういう時に便利なのね。。。


さて、このエラーメッセージをググってみると分かるのですが、SSL 関連の Exception のようなのです。はて、マンホールマップに SSL 関連モジュールなんか使ってたっけ?? 何よりも仮に使っていたとしても、実行コードは Twitter4J の中だし、指定しているのは Key と Secret だけで変えようがないし、他のサーバー環境だと動いちゃうし・・・ 念のため API Key と Secret を新たに取得し直して見ましたが、状況は変わりませんでした。


次に行ったのは JDK と Tomcat のアンインストール、および再インストールです。環境は CentOS だったので、 JDK のアンインストールは以下の手順で行いました:
# yum list installed | grep jdk  (インストール済み JDK を確認)
java-1.7.0-openjdk.x86_64
java-1.7.0-openjdk-devel.x86_64
jdk.x86_64              2000:1.7.0_79-fcs (候補は3つ、全部削除してもよいと判断)

# yum remove java-1.7.0* (上2つをアンインストール)
# yum remove jdk* (一番下をアンインストール)

同様にして、Tomcat も以下の手順でアンインストールしました:
# yum list installed | grep tomcat (インストール済み tomcat を確認)
tomcat6.x86_64          6.0.24-90.el6   @base
tomcat6-admin-webapps.x86_64
tomcat6-el-2.1-api.x86_64
tomcat6-jsp-2.1-api.x86_64
tomcat6-lib.x86_64      6.0.24-90.el6   @base
tomcat6-servlet-2.5-api.x86_64 (候補は6つ、全部削除してよいと判断)

# yum remove tomcat6* (まとめてアンインストール)

でもってそれぞれを再インストールします:
# yum install java-1.7.0-openjdk-devel
# yum install tomcat6 tomcat6-admin-webapps

これで Java と Java アプリケーションサーバーはまっさらな状態に戻りました。この状態でマンホールマップの JAR をインストールしてアクセスしたところ・・・ 何も変わらない・・・ orz


全く原因が思いつきません。いよいよヤバい。 改めてこの ECDH なるものを調べてみると暗号化のアルゴリズムっぽいようでした:
ECDH アルゴリズムの概要

暗号化アルゴリズムの、鍵の交換の所で(しかも今まで動いていたものが、ある時から)動かなくなった、ということになります。いよいよ OS レベルの中身がぶっ壊れてしまったか?? と思ったのですが、最後の希望を託してインストールした全ライブラリを更新してみることにしました:
# yum update -y
  :
  :
  :

# /etc/init.d/tomcat6 restart

で、Tomcat をリスタートしてアクセスしてみたら・・・ 直りました! 助かった!!
2015122901
 ↑直ったのはついさっき


後は緊急運用サーバーからこちらに切り替えれば対処完了(予定)。 結局「これ」という直接の原因は分からなかったけど、古いライブラリでは対応しない機能を使っていた、ということなんでしょうかね~。

自分が作って運用しているウェブサービスの多くはクラウド上で動いてますが、このマンホールマップに関しては自宅サーバーで(更に言えば ThinkPad で)運用することにまだこだわっています。今回のエラーはその信念を揺るがすものでしたが、とりあえず解決できました。もうしばらく自宅サーバー運用を続けることができそうです。 v(^o^)



このページのトップヘ