SSL, 運用管理

老若男女の皆様初めまして。

映画大好き下っ端新米ツチノコのshirokumaと申します。

ツチノコなのにshirokumaです。ʕ゚ᴥ゚ʔガオー!!

 

ところで皆さん『ターミネーター:新起動/ジェニシス』は見ましたか?

これから見る方はぜひターミネーター1と2を予め見ることをオススメします!

 

あ、watakenさん!僕が読んでるライトノベルはこちらですよ!

 

さて、本題ですが今回の記事はSSLに関するお話です。

 

shirokumaは主にDMMサービス運用を担当しているのですが、

サービス運用を行う上でSSLの更新は必須の定期業務です。

サービスの運用を行っているエンジニアの方であれば皆さん一度は経験があると思います。

 

そんなSSLについて総務省から以下の様な発表がありました。

http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/enduser/security01/12.html

 

SHA-1からSHA-2への移行についての発表です。

SHA-1からSHA-2への移行にて最も影響を受けるものはフィーチャーフォン(ガラケー)だと思われます。

 

なので、各キャリア様からも以下の様なお知らせが出ております。

NTTdocomo様

https://www.nttdocomo.co.jp/info/notice/pages/150715_00.html

KDDI様

http://www.kddi.com/important-news/20150715/

SoftBank様

http://www.softbank.jp/mobile/info/personal/news/support/20150715a/

 

一部のフィーチャーフォン端末ではSHA-2に対応できていない実情があります。

この辺りは各社の運用を行っているエンジニアが頭を悩ましているかと思います。

shirokumaもその一人です。タスケテ!

 

さらには、先日シマンテック様よりこんな発表がありました。

以前は必須となっていたクロスルート証明書の設定が今後はサーバの用途に合わせて有無を選ぶ事になりそうです。

 

そんな紆余曲折を辿りそうなSSLの中間証明書についてのナレッジご紹介致します。

SSL証明書の更新業務はshirokumaの様にエンジニアとして日が浅い人間が実施する機会が多いかもしれません。

そんな人達の助けになれば幸いです!

 

事の発端はshirokumaがSSL更新作業を行った後の中間証明書の正常性を確認をしている時でした。

弊社では確認手段としてmodern.IEのXP環境にてIE6のブラウザで階層構造を確認していました。

これは以下の二点を踏まえてshirokumaが決めた運用となります。

  • 最近のブラウザでは中間証明書をキャッシュする機能があるので確実な確認手段として不適切である。(初期のIE6にはキャッシュ機能はありません)
  • 実際にユーザーが見るのはブラウザを使うのだからできるだけブラウザで行いたい。

弊社では中間証明書を適用する際はクロスルートを証明書込みのものを利用しているのでXP環境では4階層に見えるはずです。

 

ʕ゚ᴥ゚ʔ  「さて、証明書更新も終わったし今日の晩ご飯何しようかなぁ・・・・・・・・ん?」

shirokuma-001

 

三階層になってるうううううううううううううううううううう!?!?!?!?!?!?!?!?!?

ええ。焦りましたよ。そりゃもう。

設定した箇所や手順を見直しても特に間違っている点はありません。

試しにテストページをフィーチャーフォンで開いて見たところ正常に開けました。

 

ʕ゚ᴥ゚ʔ  「クロスルートが適用されているのに3階層で見える・・・・?」

002

ʕ゚ᴥ。ʔ  「ルート証明書が自己証明しているように見え・・・・る・・・・?」

 

青狸に助けを求める眼鏡少年の如き勢いでシマンテックカスタマーサポートに連絡を取りました。

すると以下の様な事を懇切丁寧に教えてもらえました。

※シマンテックカスタマーサポート様、本当にありがとうございます。

 

Q : そもそもブラウザで見る事ができる『4階層』と『3階層』って何が違うの?

A: 違いは『VeriSign Class 3 Public Primary Certification Authority – G5』(通称:G5証明書)がOS/ブラウザにインポートされているかどうかで変わります。G5証明書はシマンテック(旧:ベリサイン)のルート証明書です。ルートのG5証明書はブラウザの階層チェーンには表示されない仕様なので、G5証明書がブラウザにインポートされていれば3階層』『G5証明書がインポートされていなければ4階層』といった形で表示されます。

 

詳細を以下の表にまとめてみました。

003

 

 

Q : G5証明書がインポートされていない環境って?

A: 最近のブラウザではPC/スマフォ問わずにG5証明書が予めインポートされています。ですがwindowsXPのSP2以前やフィーチャーフォンの一部端末はG5証明書がインポートされておらず、『VeriSign Class 3 Public Primary CA』(通称:G1証明書)がインポートされています。G1証明書は直接G3証明書をチェーンする事ができないので必ずG5証明書が必要となります。

 

Q : G5証明書って二種類あるの?

A: 非常にややこしいのですが、『VeriSign Class 3 Public Primary Certification Authority – G5』は全く同じ名前でルート証明書とクロスルート証明書がそれぞれ存在します。なので、証明書のChainを確認する際は表示されている『VeriSign Class 3 Public Primary Certification Authority – G5』がルート証明書なのかクロスルート証明書なのかを必ず確認してください。

※shirokumaがXP環境で確認した際に自己証明されていると見えたものはG5ルート証明書がG5クロスルート証明書を証明していた結果です。ややこしいですね。

 

—–

SSLは普段業者から発行されたものを手順に従って適用していたので深く調べた事が無かったのですが、シマンテックカスタマーサポートに問い合わせて色々聞いてみると奥が深かったです。
頂いた情報を元に弊社のXP環境で3階層に見えた理由を調べてみると……..

 

ʕ゚ᴥ゚ʔ  「あ、WindowsUpdateでIE6がSP3にバージョンアップしてる」

※IE6のSP3以降は『VeriSign Class 3 Public Primary Certification Authority – G5』がインポートされています。

「環境変わってるじゃねぇか!」と言われました。しょうもない理由で申し訳ありません・・・・・orz

 

—-

今後のSSL証明書更新後の中間証明書確認方法について

カスタマーサポートの方からお話を聞いた結果以下の方法が現在のbestと考えております

■対象SSLがインターネットから参照できる場合

Symantec SSL Toolboxを初めとしたインターネット上の確認ツールを使うのがbestかと思います。ただし使用する際はツールがどういった条件(確認する際に使用するルート証明書等)についてよく確認してから使用してください。ちなみにSymantec SSL Toolboxは『VeriSign Class 3 Public Primary Certification Authority – G5』のルート証明書を前提で確認するとの事です。

■対象SSLがインターネットから参照できない場合

Linux環境にて以下の様なopensslコマンドを実行してChain情報を確認する方法がbestかと思います。

 # openssl s_client -connect example.dmm.com:443 -showcerts

 

一先ずこのポリシーで今後は確認をしたいと考えています。

もっと良い方法をご存知の方が居ましたら教えて頂ければと思います!!

—-

ついでに聞けたこと

『VeriSign Class 3 Public Primary Certification Authority – G5』がインポートされているブラウザにてサーバ証明書が設定されたページにアクセスすると中間証明書が設定されていないor間違って設定されていたとしてもブラウザが自動で中間証明書(G3証明書)をダウンロードしてChainしてくれる機能があるそうです。すごい!

※推奨はされていません。必ず正しい中間証明書を設定しましょう

セキュリティ, ネットワーク, 運用管理

本日 「うるう秒」の挿入が行なわれましたが、みなさま無事だったでしょうか?

参考)  閏秒 – Wikipedia

DMMで行なった「うるう秒」対策は以下の6点です。

  1. うるう秒による影響調査
  2. ネットワーク機器の対策
  3. ゆっくり時刻を合わせるNTPサーバの構築
  4. 大量のサーバのNTPの設定変更
  5. パブリックNTPサーバとの通信遮断
  6. 当日待機

うるう秒による影響調査

ベンダーからのアナウンス情報、3年前の事例、NTPのプロトコル調査、等を行なって以下の問題があることを事前に洗い出して、チーム内周知を行ないました。

  • うるう秒で問題が発生する要因は大きく2つ。
    • NTPプロトコルでうるう秒対策に使われる、リープインジケータ(以下LI)をうまく処理できないLinuxサーバが存在する。
    • うるう秒挿入をうまく処理できないアプリケーションがある。
      • 60秒の挿入、時間の巻き戻り、にうまく対応できないソフトウェアがある。
  • 3年前には、MySQL、Java、で高負荷になる事例があった。
  • LIを受信しなければ、LIに起因する問題発生は回避できる。
    • LIを受けるタイミング(うるう秒挿入の24時間前からうるう秒挿入までの時間)でNTPサーバを停止すれば問題は回避可能。
    • LIを送信しないNTPサーバを使うことでも回避可能。
  • NTPをslewモードで動作させれば、ゆっくり時間を合わせるので時間の巻き戻りをある程度回避できる。
    • ただし、NTPの古いバージョンではうるう秒の時のslewモードにバグがある。
  • ネットワーク機器についての情報は各ベンダが情報を出してくれている。
    • 問題があるものはファームウェアを上げることで対処可能。
    • ファームウェアを上げられない場合は、NTPサービスを停止することで問題回避は可能。

ネットワーク機器の対策

機材によって以下の2つ対策を使いわけました。

  • ファームウェアのアップデート
  • 前日からのNTPサービスの停止

ゆっくり時刻を合わせるNTPサーバの構築

LIを流さずに、ゆっくり時刻を合わせるNTPサーバがあれば、うるう秒による問題は回避できます。

そんな製品がありました。

このアプライアンスサーバを最上位(stratum 1)のNTPサーバとして、複数のNTPサーバを用意しました。

大量のサーバのNTPの設定変更

DMMには大量のサーバがありますが、そのサーバのNTPの設定を確認してみたところ、いろいろなNTPサーバを参照していました。

なんてこったい。

Ansibleを使って、一気にNTPサーバの設定変更を行ない、NTPサーバの再起動を行ないました。

設定の標準化できて一石二鳥。

パブリックNTPサーバへの通信遮断

DMMには本当に沢山の機材があって、上記の対応をしても、更新漏れの機材がある可能性があります。

万が一に備えて、前日から24時間、参照している可能性があるパブリックNTPサーバへの通信を遮断しました。

ルータのルーティングテーブル上で、/32の経路をdropする、という乱暴なことをしています。

当日待機

念のため当日待機もしましたが、残念なことに、幸いなことに、何もありませんでした。

めでたしめでたし。

小ネタ, 運用管理, 雑談

サーバが重いというのでステータスを確認してみた。

 

load average: 4140.33, 3163.64, 1793.70

 

ロードアベレージは一定時間内の CPU の待ちプロセス数の平均値で、uptime というコマンドの出力の場合、左から「過去1分」「過去5分」「過去15分」の値を確認できます。

4000超えは、はじめて見たよ。

銀行のATMに4000人並んでるイメージですな。

 

※ちなみに社内ツール用のサーバで、サービスに投入してるサーバじゃありません。念のため。

イベント, インフラ全般, 勉強会, 運用管理

こんにちわ。ibuchoことテコラス株式会社の伊勢と申します。先日元同僚のtagomorisが書いたツチノコブログエントリをFB上で弄ったら、自分がゲストエントリを書く羽目になってしまいました。

過去のエントリを見ると比較的エンジニア向けの内容が多いのですが、私は現場を離れてはや十数年。どちらかというと老害の部類に入る人種でして講演で話したり雑誌などに寄稿する内容も技術論というより精神論に始終しています。そこで今回はエンジニアにとって業務上参考になるようなノウハウやTIPSではなく、去る3月13日-15日に行われた情報系を学ぶ全国の学生を対象としたインフラ技術を競うICTトラブルシューティングコンテストについて話してみたいと思います。

私はICT教育推進協議会(以後ICTEPC)のネットワーク教育ワーキンググループの主査をしているのですが、この協議会内で学生が主体になって実施するトラブルシューティングのコンテスト実施に関する企画が立ち上がり,すぐさま開催検討が開始され,昨年2014年3月にまずはこういったコンテストに慣れている大阪情報コンピュータ専門学校にて第1回ICTトラブルシューティングコンテスト(以後ICTSC)が実施されました。

ICTSC1

ICTSCはコンテストの問題作成と企画運営を学生が担い、学校関係者、社会人はサポーターに徹するという立ち位置で進めています。しかし、第1回はICTEPCにとって初めての開催ということもあり、運営の学生は帝塚山大から2名、大阪情報コンピュータ校から2名というたった4名の運営チームで進行したため、帝塚山大の日置先生、大阪情報コンピュータ校の山口先生にかなり労を取って頂きました。また開催にあたり以下のような工夫を施しました。

・趣旨に賛同する企業に協賛をお願いする。

・関西方面だけではなく全国の学校学生を対象とする。

・出題範囲はネットワークだけではなくサーバミドルウェア、アプリケーションも含む。

しかし一応全国の学校学生を対象とはしていましたが、知名度が低いせいか第1回の参加チームは九州から1組、中国地区から1組、四国から2組、関西から5組とNSCへの出場経験のある関西方面の学校が多く、関東からの出場校は東京の日本電子専門学校のみでした。

そこで、関東以東の学生も参加しやすいように2014年8月に第2回大会を都内に校舎のある日本電子専門学校に会場をお借りして開催しました。この時、運営学生15名、参加チームは10組あり、関東から5チーム、関西から3チーム、四国から1チーム、そして東北から1チームが参加し出場校の幅が広がっていきます。ICTSC2

そして2014年9月に第3回ICTSCプロジェクトがスタートします。過去2回大会の経験を踏まえ、第3回は色々と改善を図りました。

まず、第2回大会の学生運営委員15名は関西と関東の学生で構成されていましたが、通常の打ち合わせをLINEやSkype等で行い、月に一度の頻度で関西の学生が上京し運営委員会を行いました。当然関西から上京する学生の交通費と宿泊費がかかります。知名度が低いため協賛企業も少なく、賞金や必要経費、コンテスト当日の運営学生用旅費交通費に加え、事前打ち合わせのための旅費交通費を捻出する事は非常に困難なのです。

そこで第3回の定例運営委員会はシスコシステムズ社の東京オフィスと大阪オフィスにそれぞれの運営学生が分かれて集合し、テレプレゼンスシステムにてテレビ会議を行う事にしました。このテレプレゼンスはマルチスクリーンであり、また話者の声に反応してカメラが切り替わるため、まるで同じ会議室の円卓で打ち合わせているかのように感じられ離れていても違和感がありません。

テレプレ

ただし、月一回の運営委員会だけでは不十分であり、運営学生達は随時Skypeによる打ち合わせを何度もやっていたようでした。また、日々のコミュニケーションはSlackでやりとりし、進捗管理にはRedmineを使用しました。

Redmineは運営委員の進捗だけではなく、結果的にコンテスト本番の出題と回答のツールにも利用されています。作業指示やトラブル発生等のチケットを運営が参加チームへ発行し、そのチケットを参加選手がクローズしていくという実際にインフラの現場で起きている実践さながらの状況を再現しています。

Redmine

また第1回、第2回ともコンテストの前々日に機材搬入し、前日にセットアップ、コンテスト終了後に機材搬出という非常にタイトなスケジュールでした。そのため、機材に不具合は無いか、コンフィグレーションに間違いは無いか、運営が想定している問題と回答が実際に不整合無く成立するかどうか、問題の正解不正解によって次の問題に影響は無いかなどの検証が十分にできず、運営学生やサポータである先生方が深夜まで、場合によっては徹夜で検証する羽目になっていました。それでもコンテスト当日には機材の不具合や問題の不整合が発生し、運営側のリアルトラブルシューティングによって時間が割かれ、予定された問題を全て出題する事ができなくなった事もあります。

そこで、第3回は帝塚山大学に一週間前からコンテスト会場を提供していただき、十分な事前検証を行う事でコンテスト前日、当日の運営負担を軽減すると共にコンテスト中のトラブルを最小限にすることができました。そして予定していた問題を全て出題する事ができ、コンテスト自体も大成功という形で幕を閉じました。今回出題した問題の中で回答率が非常に低かった問題は次回に持ち越しする予定なので、残念ながら問題と回答は非公開とさせていただいています。

HS1HS2HS6HS5

最後に一番大きな変更はコンテストに参加する際の制限を廃止した事です。

コンテストの問題はシスコシステムズのルータやスイッチなどの実機を操作する事を前提としていたので、第1回、第2回はCNAの開催校に限定して参加募集をしました。また、ICTEPCが主催していたため、主にICTEPCの一般会員学校からしか運営者も参加者を募集しませんでした。今回はICTSC実行委員会をICTEPCとは別に組織し、ICTEPCの会員であるなしを問わず、CNAの開催校如何にかかわらず全国の学校と学生を対象としました。

また、第1回、第2回は出題範囲をネットワークからサーバミドルウェアとしてはいましたが、結局ネットワークとサーバ問題の比率は5対1ぐらいに偏っていて、サーバ担当の学生から「ping打つ程度しかやることがない」などの感想を頂いていました。そこで、今回は運営学生もネットワーク専攻と情報科学専攻、アプリケーション専攻者をバランスよく勧誘し、ネットワーク以下とサーバ以上の問題バランスを5対5ぐらいに調整してみました。第1回、第2回に参加経験のあるチームは問題の難易度に戸惑ったようではありますが、逆にCNAを開校していない学校の学生でもサーバ以上のコンポーネントに造詣のあるチームにとってはフェアに戦える問題構成となっています。

今回はクリエーションライン株式会社、シスコシステムズ合同会社、テコラス株式会社、さくらインターネット株式会社の4社からご協賛を頂きました。アンケートによると協賛各社のご講演が非常にためになったとか、懇親会で企業の方々と会話できてよかったという意見がありました。

コンテスト後に参加選手からいただいたアンケートでのコメントを紹介します。

● 自分の程度が計れる素晴らしい機会。今後も参加者として出たい気持ちがある反面、運営側で技術を学びたい、経験を積みたい気持ちもある。

● 問題文が分かりにくい。そういった趣旨なのかもしれないが、何を探せばいいのかすら分からない問題だと難しい。

● 本当におつかれさまでした。高難度の問題に出題者の本気が見えており身が震える。

● このコンテストを学生主体で開催しているのは、純粋に凄いと思う。運営者の人たちくらいに知識をつけたいと思った。

● どの問題も質の高い問題で勉強になりました。

● 懇親会で多くの方と話をすることができたので、良い刺激を受けました。

● 参加者の少なさには少しがっかりしました。

● redmineで報告する方法が斬新であると感じた。

● 所々グダグダだったり、必要情報が足りなかったりしたので、もうちょっと予行すべきだったのでは?と思う。

● 事前に出題範囲を教えてくれていたことは非常に有り難いと感じた。名前は知ってるけど詳しくは知らないというものも多かったので、予習に実践と続き、非常に効果的に学習することができたと感じる。

● 問題の難易度が高くてなかなか解けず。もっと勉強しないといけないと思える良いコンテストでした。

● 難しく、苦しかったですが、思っていたよりも早く時間が過ぎていて充実していたのだと感じました。

● 今回の問題は自分のレベルではなかなか解けるものでは無かったです。運営をやるためにはもっと知識を付けていく必要があるととても感じたので追い付くためにも勉強をし続けていきたいです。

● 次回も出来たら参加したいです!

どうやら、ちょっと問題が難しかったようですね・・・ それでもその難しい問題を楽しんでもらえたようでよかったです。

また運営に携わった学生達からは以下のような感想を頂きました。

● サーバ構築や監視を中心に、学生生活で得たものを全力で投入したつもりでしたが、振り返ると改善したい点がたくさんあります。次のコンテストは全力でサポートする側に回りたいと思います。

● 今回運営に参加して、学生運営委員のレベルの高さに圧倒されました。より高みを目指すために何が必要か、具体的にどう行動すれば良いかを考えることができる人を見て、それをやろうとしても出来ない自分に気づくと同時に憧れも抱きました。

● 今回は主にサーバ周りを担当しましたが、ネットワークなど自分があまり触ったことない部分を勉強したいと思う良いきっかけとなりました。コンテストに関わったみなさまに大変感謝しています。

● 今回初めて運営に参加して、主に電源や配線などのL1を担当させていただきました。運営を通して周囲との知識や経験の差や、如何に自分の認識している範囲が狭かったかを認識し、これからさらに努力を重ねて行かなければならないと考えさせられ、とても大きな経験を得ることができました。

● 私は今回リーダーという仕事を通して改めて自分にとって足りない部分などを見つめ直すことができました。自分を見つめ直す機会に出会えたことに感謝しています。そして成功まで導いてくれたメンバーのみんなに大変感謝しています。

● 学生スタッフの仕事は発見の連続でした。運営の苦労,チームでトラブルを解決することの魅力,そして4月から働く仕事に対する新たな楽しみ。そしてみんなと作業したことで、刺激を受け、学びに対する向上心が増しました。今後も付き合いが続くであろう、素晴らしい仲間に出逢えたことに感謝。もっと色々な方にコンテストについて知って頂くために、技術力は勿論、その他の部分でも尽力します。

● 今回は主にネットワーク設計を担当させてもらいました。入院中、後輩が悩み抜いて設計した基礎に、4年間で学んだノウハウを全て注ぎ込んだ魂のこもったネットワークです。今後も当大会の発展を願うと共に、全力でサポートしたいと思います!

● 何もわからないまま先輩達に連れられ運営初参加!気づけばラスボスを担当していました。

● 名前しか知らない技術を準備期間中に勉強し始めて問題にしたので、ものすごく難しかったですが、その分ものすごく勉強になりました。

● 前回に引き続き運営をさせていただきました。自分に出来る事を探した結果序盤に大阪で作業出来なかったのは痛いところです。その分終盤に力を発揮できていたと思います。皆さんの知識量に触れ、自分に出来る仕事を増やすため更に勉強しようと奮起する要因になりました。

● 今回のトラコンは本当にレベルが高く、自分の知識の少なさや視野の狭さなどを痛感しました。また、改めて自分はネットワークが好きだと再認識し、もっと努力しなくてはと思いました。長いようであっという間でしたが、今回のコンテストに関われたこと、本当に感謝しています。

● 今回のトラコンを通してまだまだ自分の知らないことがいっぱいあることに気づかされました。また、今まで気にしていなかったタイムキーパーの大切さを知りました。僕が携わるのは今回で終わりだと思いますが、後輩に引き継いで次回はもっと良い大会にしてもらいたいです。

● 参加するのは、今回が初めてでした。実力、知識不足であまり力にはなれませんでしたが、自分のできることで頑張りました。トラコンを通して、学生の対抗、生き生きしている姿を見て、彼らのように頑張れるようにもっと学んでいきたいと思いました。

● 今回、初めて参加させていただいていろいろと勉強になりました。大学に入学してから何かしないといけないという考えが自分の中にあり、今回のトラコン運営に誘われ参加させていただきました。参加が初めてでわからないことも多々あり自分の実力と知識があまりにも不足していてもっと勉強が必要だなと思いました。

● 今回、初参加です。ほとんど力になれませんでしたが、皆さんに助けられました。皆さんの生き生きたとした姿が見れたので良かったです。

● 第1回大会は参加者として第2回、そして今回と運営として携わらせていただきました。回を重ねるごとに規模も大きくなっており、自分が触ったことのない新しい技術の導入もあるため貴重な経験を得ることができました。

運営の学生も刺激を受けてさらに精進しようという気持ちになったようでうれしく思います。昨年9月のキックオフからずっと彼らを見てきましたが、皆、誰も彼もが積極的で向上心があり、責任感と実践力のある学生諸君ばかりでした。自分が学生だった時、これほどまでに積極的かつ責任感を持ってミッションを実行できたかどうか疑問です。いや、今でさえ彼らと同じような姿勢で仕事や様々な活動に対峙し対処しているだろうかと反省することしきりです。

今回、社会人で構成される実行委員は学生の運営をサポートする立場ではありますが、様々な事に気付かされ、学ばせてもらったのはこちらの方だったのではないだろうか?と痛感している次第です。本当にダメな大人たちで申し訳ありません。ごめんなさい。ごめんなさい。

最後に素人撮影&編集ですが、実行委員会でPVを作成しましたのでご覧下さい。コンテストのライブ感が伝わると思います。次回は8月後半ぐらいに第4回を開催する予定であり、運営学生、参加選手、協賛企業、実行委員など公募していきますので、皆様よろしくお願い致します。

Hadoop, クラウド, コラム, 運用管理

初めまして、tagomorisといいます。今回縁あってゲストでエントリを書くことになりました。実に感慨深い気分です。

さて本題ですが、DMM.comを含めた多くのWebサービス・インターネットサービスでは、今やデータの収集・処理・分析といったタスクが非常に重要なものになっていることは多くの方に賛同をいただけるものと思います。近年ではIoTというキーワードもよく話題になります。増え続けるデータの処理をどのようにするか、といった点に悩んでいるサービス事業者の方は多いのではないでしょうか。

この種のデータ処理・分析をどこでどうやって行うか、という問題は通常のWebサービスの開発とはかなり異なる知識と経験を要求されます。特にHadoopを中心とした分散処理基盤のデプロイとメンテナンスはこれまで多くの開発者を悩ませてきました。

一方、近年ではデータ処理・データ分析に特化したサービスもいくつも出てきました。自分でHadoopクラスタのセットアップ・運用をしなくても利用可能なこれらのサービスは特に開発者の少ないスタートアップで広く利用されるようになり、耳にされることも多いかもしれません。

このエントリでは、特にスタートアップ企業、あるいは既存企業の新規事業などにおいてデータ処理・分析基盤が必要とされるとき、どのような選択肢があるかについて概要を書いてみようと思います。

総論

まず原則ですが、これは極めて簡単で「サービスを使いましょう、作ってはいけません」です。

そのスタートアップ企業が何を専門とするかにもよりますが、多くの場合、それらの企業は自前のデータセンタなど持ってはおらず、またソフトウェアエンジニアの数もそう多くはないでしょう。そういった企業にとって自前の分散処理クラスタの保持と運用は金銭、エンジニアリングの両面で極めて高コストになります。

サービスを使う場合についてもいくつかの選択肢があります。日本国内でよく選択されているのは以下のあたりでしょう。

  • Amazon Elastic MapReduce
  • Amazon RedShift
  • Treasure Data
  • Google BigQuery

今のスタートアップ企業の多くがAWS上でサービスを展開しているだろうことを考えるとAmazon Elastic MapReduce(以下EMR)やAmazon RedShift(以下RedShift)がまず選択肢となるかもしれません。EMRはS3に格納したデータを処理するHadoopクラスタを一時的に起動できる便利なシステムで、Hive, Pig などのHadoop向けDSLなどの他に自分で記述・コンパイルしたMapReduce処理そのものを走らせることもできます。RedShiftは分析用途の分散データベースを起動できる他社にもあまりない高機能サービスです。

数年前に登場したTreasure Data社のサービスはフルマネージドHadoopとでも言うべきもので、裏側で動いている仕組みとしてはHadoopとHive(あるいはPresto)ですが、クラスタの管理やデータ保管はすべてサービスの一部として提供されており、ユーザが面倒を見る必要がない、という点が異なります。
また保管データがスキーマレスなので、データ投入側からはいつ・どのようなタイミングでもデータの内容を変更することが可能です。これは特にサービス内容を頻繁に変更するスタートアップには良いかもしれません。

Google BigQuery(以下BigQuery)は少し趣の異なるサービスで、サポートされている言語はSQL-Likeな言語一種類のみです。実行時に裏側で何が起きているのかは基本的には隠蔽されており、実際に裏側はHadoopではありません。スキーマ管理やデータ保存などもBigQueryの一部として提供されており、フルマネージドサービスのひとつと言えるでしょう。
Googleの保有する巨大なクラスタで膨大な数での並列分散処理が行われることが特徴で、大容量データに対するクエリでもかなり速く結果が返ってくることが特徴です。ただしGoogleのクラウドサービスらしく、ちょくちょくクエリの失敗などが起きるため、ユーザ側で適宜リトライしてやらなければならない、などの注意点もあります。

さてスタートアップ企業にどのサービスが向いているかということを考えると、AWSのユーザにとって、EMRやRedShiftは利用例も多くとっつきやすいとも言えるかもしれません。一方で効率的に利用しようと思うと、EMRはHadoopの、RedShiftは分散データベースの知識が必要とされ、そのあたりの知識をもったエンジニアがいなければ高パフォーマンスの利用は難しくなるケースも多いでしょう。スキーマの調整やデータ保管形式・場所・期間などの管理も自分でやる必要があり、手をかければ便利に使える一方で、手をかけることができなければデータ量やクエリ回数に対して高い利用料金となってしまうケースもありそうです。

BigQueryはGoogle Cloud Platformの1サービスということになりますが、特にGoogleのクラウドサービスを使っていなくても簡単に利用できます。実際にAWS EC2を使っていながらデータ分析にはBigQueryを利用しているケースは多いようです。また現状(2015年2月)では利用料金が突出して安く、なんとBigQueryのデータ保存料金はAmazon S3の料金よりも安いのです。スキーマ管理が行われていること、直接クエリを実行可能であることを考えると、これは驚くべきことです。クエリ実行料金を含めても安く、自分が聞いたところでは数億行/dayもしくはそれ以上の規模のデータで運用していても月に数百ドル(桁を間違えてないよ!)の費用で済んでしまった、という話もあります。既にFluentdを用いていれば、データ投入はプラグインをひとつ足すだけでできてしまうという導入の簡単さも魅力かもしれません。

FluentdといえばTreasure Dataのサービス、という選択肢もあります。こちらもFluentdの設定ひとつで簡単にデータを投入できる上、BigQueryでは必要なデータのスキーマ管理が不要という利点があります。フルマネージドサービスとしてBigQueryと比較してみると、クエリの安定度ではこちらの方が上かもしれません。
またクエリのスケジュール実行や外部データベースへのデータ連携など、他のサービスが持っていない機能をいろいろ有していることも特徴です。少し高めの料金を払ってでも可能な限り外部サービスを利用して社内エンジニアリングコストを下げようと思うのであれば、有力な選択肢になることでしょう。

いくつかの特例となるトピック

総論としては以上のようになるのですが、特に上述の総論から逸脱するケースがいくつかあります。その中でもぱっと思いつくものに以下のものがあります。

  • 機械学習やグラフ処理などが主たる処理内容になるケース
  • 既に大規模なデータセンタを自社で保有しているケース
  • データを自社外に出すだけで事業リスクになるケース
  • 風土として自社でホストするというケース

まず目的とするデータ処理が主に機械学習やグラフ処理となる場合ですが、こういった種類の処理をホストしているフルマネージドサービスは実質的に無いといってよいでしょう。なのでこの場合、Amazon EMRの使用を検討するか、あるいは自社でHadoopクラスタをホストするということが有力な選択肢となります。特にSparkの新しいバージョンを使用したいなど、EMRのアップデートを待っている余裕がなく、またそれが事業において重要な価値を持つ場合には自社でHadoopクラスタをホストするのが重要な選択肢になるかもしれません。一方Treasure DataではHivemallというHiveのUDFとして動作するライブラリもサポートしていますから、このライブラリがサポートする範囲の処理だけを行いたいということであればTreasure Dataのサービス利用も選択肢としては有効となります。

既に大規模なデータセンタを自社で保有している場合ですが、このケースであればHadoopクラスタの調達・運用コストは下がります。ハードウェアやOSの運用のためにITインフラ運用の専門チームがいるのであればなおさらでしょう。しかしHadoopそのものの運用・アップグレードなどにかかるコストなどは過小評価するべきではなく、慎重に判断する必要があると言えます。

扱うデータが非常にセンシティブなものである場合にも注意が必要かもしれません。実質上、現在の各種クラウドサービスにおいて、技術的な問題による情報漏洩のリスク等はほとんど考慮する必要はないと思います。しかし非常にセンシティブなデータを他社管理のストレージに置いているという話が公表される際、その話の伝わり方がある種の誤解を含んでしまう可能性はあります。一度の風評被害がサービスの継続において決定的な悪影響を及ぼしかねないようなケースでは、そもそも外部にデータを最初から置かない、という選択肢もあるかもしれません。

また最後に、会社の風土あるいはポリシーとして自社でHadoopクラスタをホストする、というケースも考えられます。外部サービスに依存せず可能な限り自社内でOSSを利用して解決する、という選択をとる会社は多くはないものの存在します。エンジニアの採用や動機付け面の理由であることが多いでしょうか。これはこれ、というか、他人が口を出すことではないですね。

まとめ

主にスタートアップのような状況の各社においてデータ処理・分析基盤を必要とする場合において、主にどのような選択肢があるか、どういった判断基準でそれらを採用すればよいかについて簡単に述べました。

最初はもうちょっと広い範囲を見渡した内容で書こうかと思っていたのですが、あまりに長文になりそうだったので今回は主旨に合わないかなあと思ってダイジェスト版でお送りいたしました。フルバージョンを読みたい方はコメント欄やブックマークコメントにわっふるわっふると書いてください。と思いましたが自分のブログじゃないんでした。

このエントリの内容がみなさんの参考になることがあれば幸いです。

PAGE TOP