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を利用して解決する、という選択をとる会社は多くはないものの存在します。エンジニアの採用や動機付け面の理由であることが多いでしょうか。これはこれ、というか、他人が口を出すことではないですね。

まとめ

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

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

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

SSL, 失敗談

世の中ではSSL証明書のSHA-2への移行が騒がれていますね。
Chromeが突然警告出すようになったので、あまり詳しくない友人がビックリして「何これ?開くと危険なの!?」と私に聞いてきたりしました。(これは私が以前「この緑色は安全の証なんだよ」と教えたせいでもありますが)

そんな中、とあるサイトのSSL証明書が有効期限を迎えたので、SHA-1・SHA-2どちらで更新するか事業部に相談、PC専用サイトということでSHA-2で更新したのですが、ある問題が発生してしまいました。

その問題とは「MacOS Mavericks+Chromeの組み合わせだけ、SHA-1と同じ警告が出る」というイレギュラーなもの。WindowsでもYosemiteでも緑色になるのに、何故かMavericksだけ・・・

あ、ここでSHA-1の警告についておさらい。
参考資料:https://www.jp.websecurity.symantec.com/sid-partner/products/pdf/chrome_sha1deprecation_201409_1.pdf

■Chrome v40(2015/2/20現在最新)

有効期限終了日(GMT) SHA-1/SHA-2 アドレスバーの表示
2016/5/31以前 SHA-1 緑色
2016/5/31以前 SHA-2 緑色
2016/12/31以前 SHA-1 黄色
2016/12/31以前 SHA-2 緑色
2017/1/31以降 SHA-1 白色(http:// と一緒)
2017/1/31以降 SHA-2 緑色

■ Chrome v41(2015/4 一般リリース予定)

有効期限終了日(GMT) SHA-1/SHA-2 アドレスバーの表示
2015/12/31以前 SHA-1 緑色
2015/12/31以前 SHA-2 緑色
2016/12/31以前 SHA-1 黄色
2016/12/31以前 SHA-2 緑色
2017/1/31以降 SHA-1 赤色(取消し線)
2017/1/31以降 SHA-2 緑色

要はSHA-1で出す場合「有効期限日を2015/12/31まで」にしないと警告が出てしまい、SHA-2なら有効期限にかかわらず警告は出ない。という趣旨ですね。

では何でMavericks+Chromeだけ警告が出たのか。Symantecさんに問い合わせた結果、以下の事実が判明しました。

Mavericksは1024bitと2048bitの2つのルート証明書を持っているが、証明書の検証をする際に証明書の鍵長や署名アルゴリズムに関わらず1024bitのルート証明書を辿る挙動になる。
1024bitのルート証明書に辿りつくためにはSHA-1で署名されたクロスルート証明書が必要となるが、ChromeのSHA-2判定基準はサーバ証明書・中間証明書群全てSHA-2であることが求められるため、判定がSHA-1となりアドレスバー警告が表示される。

よく解らないですよね。はい。。ということで図解してみました。

Marvericks+ChromeのSHA-1証明書警告について

困った問題ですねぇ。教えてGoogle先生っ!

google.com_cert

何この証明書。。さっさとSHA-2移行しろと言わんばかりに警告出しておいてコレかーぃ!!

取りあえずSHA-1にしろSHA-2にしろ、有効期限を2015/12/31で出すしかないのかな。。

 

CONBU, wifi, イベント, ネットワーク, 小ネタ, 趣味, 雑談

こんにちは。寒さがぶり返してきて辛いですね。2月よりDMM.comラボにて働き始めたトウマツです。よろしくお願いいたします。拝承。

今回は、ケーブルを床に養生するための治具の紹介、そして使用感をレビューしたいと思います。

DMM.comラボでは、サーバやネットワーク機器の検証を行うために、LANケーブルや電源ケーブルなどを床に這わせることがあります。これらのケーブルを床に這わせる場合、足で引っ掛けてしまう事を防ぐためにケーブルをテープで床に止める(養生する)のが一般的です。
しかし長いケーブルの場合、長さに比例して養生する距離が長くなります。数十メートルの距離を養生するのは、まるで床を雑巾がけしているような感覚で、辛く地道でとても疲れる作業なのです。
そんな苦痛を伴う作業を「やってもいいかな!」と思えるような作業へと昇華させてくれる素晴らしい治具が発売されました。それがGAFFGUNです。

まずは、公式ページの動画を御覧ください。

この動画の通りであるなら、本当にすごい! イケてる! 試したい! そんな風に感動しているうちに、ついつい輸入してしまいました。

ちなみに、今回購入したのはコチラです。
The GaffGun Bundle

 

発送や通関に時間は掛かりましたが、無事到着。ていうかデカい!!

gaffgun1

 

丁寧にスポンジで梱包されており、好印象。本体は金属製です。(たぶんアルミのキャスト)

gaffgun2gaffgun3

 

さまざまなテープの幅に対応できるアタッチメント

gaffgun4

 

公式ページによれば、このGAFFGUNで使えるテープはメーカ純正品、または紙テープや布テープを推奨されています。ですが日本で発売はおろか、国際発送もしてもらえないメーカ純正テープは簡単に入手できませんし、コストも無視できません。また、紙テープや布テープは、接着剤が床やケーブルに残ってしまうので掃除が大変。やはり、慣れ親しんだ養生テープを使いたくなるわけで、ダメ元で使ってみました。

使用した養生テープの幅は50mmのどこでも入手できるものを、そしてGAFFGUNのアタッチメントはサイズSを使いました。

IMG_3860IMG_3861

 

使えるじゃん!

[KGVID width=”640″ height=”480″]http://tsuchinoko.dmmlabs.com/wp-content/uploads/2015/02/GOGOGAFFGUN-S.mov[/KGVID]

 

IMG_3839IMG_3836

つい、色んな所を養生したくなる!

 

というわけで、このケーブル養生治具”GAFFGUN”は日本でどこでも入手可能な養生テープを用いて、腰を痛めたり、床に這いつくばることなく簡単にケーブルを養生できることが確認出来ました。

そうそう、DMM.comラボはカンファレンスネットワークをサクッと構築するチーム”CONBUさんを応援しています。というわけで、CONBUさんに、GAFFGUNをお貸しして、どの程度の威力を発揮できるかを試して貰おうという思います。おそらく、YAPC::Asia Tokyo2015 あたりで大活躍されるのではないかなと、期待しております。

ついでと言ってはなんですが、本日は2015年2月18日、技術評論社のソフトウェアデザイン3月号の発売日となります。3月号の特集記事第一弾に、「カンファレンスネットワークのつくりかた」が掲載されました。実はこの記事の元ネタの一つであるYAPC::AsiaTokyo2014はDMM.comラボも協賛しており、同時にCONBUさんも応援いたしました。この記事にはCONBUさんの無線LANや、ネットワークに対する愛が詰まった内容です。ぜひご一読ください。

 

PAGE TOP