イベント, クラウド, プログラミング, 勉強会

■ はじめまして

CROSS2016で実行委員長をさせていただいているRYOSUKEです。
Dmm.comラボさんのご厚意により、お邪魔させていただきました!!

僕らがやっているCROSSについて、ちょとだけお話をさせてください!

■CROSSって?

CROSSは、2012年から開催している、WEB/ITテクノロジーに関わる全ての人のためのイベントです。
特定の企業の特定の方だけにお話をしていただくのではなく、1つのテーマにそって複数の企業や技術、
世代などを交わらせ、パネルディスカッションをして頂くことによって、異なる価値観、その差分から
垣間見える技術や考え方の本質を皆さんに感じてもらえればと思っています!

もちろん、難しいこと考えなくても、普通に楽しめます!
CROSSっていろいろ特徴があるんで、説明させて。

IMG_5620

■CROSSの各セッション会場について

CROSSに来られたことがある方はご存知かと思いますが、CROSSの会場は大きなホールを区切って、
ある程度周りの音が聞こえるように設計しているんです。
これは、会場全体をお祭りの縁日をイメージして作られているからなんです。
縁日って、人が多い方、盛り上がっている方を目指してみんな移動して、いろんなものを見ていきますよね?
他のイベント/カンファレンスよりも、ザワザワ感が常に感じられ、より多くの盛り上がりがある方に行って、
新しい発見を是非して欲しくて、そうしています。
※ その昔、僕がセッションをやっていたら隣のセッションが大きく盛り上がって、僕のセッションから
人がさっといなくなったも良い思い出です ><

■今年のプログラムについて

今年のプログラムは、HadoopやSparkといった分散テクノロジーや機械学習、IaaSクラウドの内情やIotといった
比較的新しいテクノロジーとされるものを始めとして、首都近郊の地方や海外と日本での働き方、そして運用の話、登壇されるのはいずれも、一線級の方々ばかりです。
普段使っているOSSのコミッターや、システムの開発者、その企業のCEOなどが集まってくださっていますので、非常に濃いエッセンスが得られると思います!

http://2016.cross-party.com/program

まずは、ご自身の興味のあるところを中心にしつつ、ちょっと外れたところもぜひ見に行ってください。

 

■なぜ横浜にした!?

横浜、普段都内で開催されるイベントに参加されている方からしたら、遠いですよね?
実は、CROSSは第3回まで新宿でやっていました。でも当日見ていて、「目当ての一つのセッションだけ見て帰ってしまう人がいる。」
「電話で呼び出されて、事務所に戻ってしまう人がいる」これって、とてももったいないなと思ったんです。

なまじっか近いから、そういうことになるのかと思って、思い切って横浜での開催にしてみたのです。
昨年の様子を見る限りでは、かなりの方が一日いて下さったのかなと思っています。
実は渋谷からは40分くらいでいけますが、プチ出張気分の横浜でガッツリ一日過ごしてください!

 

■今年の出し物

・ヒートマップ

CROSSみたいなカンファレンスやイベントで実際の人の動きって見えたら、面白いと思いません?
デザインを語るセッションに実際にいるのは、WEB系の人だったのかな?デザイナーなのか?職種は?どのくらいいたんだろう?こういったものをリアルタイムに知ることができれば、セッションを開催する側も参加している人もより良い活動ができると思うんです!※一般の方に見えるのは、どの会場にどの程度の人がいたかになり、公開はされません。
ちなみに今回のシステム(ヒートマップシステム)はさくらインターネットさんと、DMM.make AKIBAさんが
共同で構築してくださっています。こういったアイディアやモノが出てきて、試せるのも、面白いですよね!

heatmap_sequence

・最高の発想力と最低の技術力の共演

また、昨年は大変盛り上がった、ニフティDPZの言語対抗綱引きですが、今年は何か素敵なDATAが入っているかもしれない古(いにしえ)のメディアを落とす射的大会と、技術力が低い人向けのロボット対決(ヘボコン)が開催されます。射的は随時参加可能な予定ですが、ヘボコンは参加が8名までとなっていますので、早めに来てエントリーしてください!!
審査員には、技術力の粋を集めたあの方が参加されると伺っています!!

 

 

■実現したいこと

CROSSは自分の興味の外側に触れることで、自分の境界を明らかにし、その外側を知る機会を提供しています。自分のやっていることと、やれるかもしれないところ、わからないものを発見し、やりたいと思ったら、アンカンファレンスで表現することができます。
ぜひ、自分のやりたいこと(仕事の運用改善でも、新しいビジネスでも、疑問でも何でも良いです。)を認識し
楽しめるかどうか、ちょっと考えてみるきっかけにしてみてください!

また、CROSSでは、こういったカンファレンスや勉強会には会社の業務として参加して良いという文化を作りたいと思っています。今年からそういった趣旨に賛同いただける企業様を募集しリストしていこうと思っています。

ぜひ、こちらからお伝え頂けると嬉しいです。

IMG_5629

■ 最後に

だらだらと書いてしまいましたが、CROSS2016は参加者が主体となって駆動させるとてもおもしろいイベントです。ぜひ参加していただき、何かを持ってかえって頂けると嬉しいです。(※今年は実験的に無償です!)
それと、来年CROSS2017をやれることになったら、ぜひ実行委員会に参加してみませんか?
業務では絶対に無いであろうおもしろ体験が沢山出来ます!!

最後になりますが、DMM.comラボさんには、ネットワーク構築と機材提供のお手伝いをしていただきました!
また、このような駄文掲載の機会も頂けて大変うれしいです!!
また来年もよろしくね!

IMG_5639

※本文はCROSS実行委員会より寄稿させていただいたものになり、文責はすべて実行委員会にあります。

クラウド, コラム, 仮想化

はじめまして。若そうに見えて実はおっさんツチノコ、naoshizです。

今年も残すところあと少しとなりました。紅白も始まっちゃいましたね。黒柳さんテンション高いなw
というわけでぎりぎりのタイミングですが、私自身と、私の所属するXaaS部の1年をざっくり振り返ってみたいと思います。

つうかXaaS部って何するところよ?

Job Descriptionから引用しますと、

・現行基盤の運用、構築
CloudStack, vSphere を始めとする現行仮想化基盤に対する運用、構築を行います。
デプロイ、設定の自動化やドキュメントの作成等の運用改善も含みます。
・次期仮想化基盤の開発、実装
現行基盤の”次”となるシステムの開発、実装を行ないます。
要件の定義、必要な技術の調査・選定、検証から実際の環境構築まで担当して頂きます。
・仮想化に関連した技術の調査、研究
現行基盤へのフィードバックや、将来の仮想化基盤へ有用な要素技術の調査、
研究を行います。
対象範囲は、仮想化技術、オーケストレーション、運用自動化、ストレージ、
ネットワーク仮想化等、広範囲に及びます。
必要に応じて海外を含む出張による情報調査も行って頂きます。

と、こんな感じです。

当初は部としてあまり機能していませんでした。8月頃まで私とラノベの人の2名しかおらず、さらにそれぞれ他部署と兼務する形でした。

その後マネージャーに酔っ払い.jp(@r_takashima)を迎え、運用スペシャリストしろぺん先生、スーパーハカー大山くんが相次いでJoin、海を愛する頼れるSESも加わり6名のチーム編成となり、今月になって何とか体制が整いつつあります。

あとどうでもいいですが、XaaS部の挨拶は「あざーす」です。どうでもいいですね。

1~4月

仮想化基盤構築 (通称:ツチノコクラウドV(クラウドじゃないけど))

「vSphere環境100node、naoshizくんよろしくー」
ツチノコの親分から、共通の仮想化基盤構築の指示がありました。さあ困った。
それまではプロジェクト毎に、都度IAサーバを調達していました。仮想化基盤も、各自でCentOSをインストール、ローカルディスク上にvirt-installでKVM VM作成といった具合。大きな方針転換になります。

vSphereのノウハウが無いこと、少ないメンバーで確実に運用していくことを考慮して、サーバにCisco UCS、ストレージにTintriを選定。なるべくリファレンスやベストプラクティスに沿うように構築しました。

このあたりの経緯はラノベの人VIOPS10で発表しています。

5月

OpenStack Summit Vancouver & Silicon Valley視察

DSC_1728_1

初の海外出張。
当時別部署にいた@r_takashimaと若者shirokumaの3名で参加してきました。
同行した方々に迷惑をかけまくる、残念な海外デビューとなりました。その節は大変ご迷惑おかけしました。

  • 出発30分前にぎりぎり羽田到着
    いやほんと間に合ってよかった。羽田って思ってるより遠いんですねえ。。。
  • イミグレ抜けられない
    これは初心者あるある、かもしれません。おまえは具体的に何の目的でどこに行って誰と会うんだよ説明しろよ。と言われた、ような気がしましたが全く答えられず。別室行きは免れましたが、辛かった。。。
  • まさかのロストバゲージ
    Vancouver からSFO へのフライトでの話。
    Silicon Valley視察ツアーに参加するため、Vancouverを後にしSFOに向かったのですが、バゲージクレーム、待てども来ません。
    なぜか私のだけDelayedだという。。。

とまあ散々でしたが、Vancouverの美しさに感動、トラウマにならずに済みました。

6月~7月

XaaS部のお仕事と並行して、他部署のミッションクリティカルなシステムのインフラ構築を担当することになりました。
ここではNutanixを採用。やはり運用面で手がかからないことを重視しました。

8月

ツチノコクラウドVにサービスがものすごい勢いで乗り始めたため、急遽運用メンバーを増強することになりました。

この呼びかけに応じて、後にしろぺん先生がJoinしてくれることになります。

9月

VMworld 2015 US

DSC_1973_1

立て続けに2度目の海外出張。そしてまたもやらかしてしまいました。
レストランに荷物を忘れてしまったり、ホテルのカードキー落としてしまったり。その節は大変ご迷惑おかけしました。
内容については秀逸なサマリが多数ありますので割愛します。

VMwareがクラウドネイティブを強く打ち出した(Photon Platform)のがやや意外で印象に残りました。また、NSXの重要度がさらに増しているように感じました。

10月

OpenStack Summit Tokyo

我らが@r_takashima鏡割りデビュー!

11~12月

しろぺん先生中心にツチノコVのドキュメント整備、運用体制の強化に取り組みつつ、VMware Integrated OpenstackやAzurePackの検証を始めています。忘年会は@r_takashima宅にて。

来年にむけて

現行基盤の運用と改善を着実に進めることとあわせて、当社を支えるべく次世代のIaaS基盤を、引き続きフラットに模索していきます。

左隣の席では大山くんがVIO2.0+NSXを触り始めています。vMotionすげー!HAすげー!エンタープライズすげー!とかいってます。

右隣の席ではラノベの人がAzure Stackを待ち遠しそうにしています。

そんな若者に囲まれて、刺激を受けまくっております。

現行基盤の運用に軸足を置きつつ、次世代のあるべき基盤、考えていきたいと思います。

 

今年1年関わって頂いた皆様、ありがとうございました。
良いお年を!

クラウド, コラム

おはようございます。ライトノベル好きのツチノコです。 転生従者の悪政改革録読みましたよね?

さてAzure Stackの足音が聞こえてきました。

Microsoft Azure をお客様のデータセンターに
Microsoft Azure Stack は、マイクロソフトのハイパースケールのパブリック クラウドで実証済みのイノベーションを、お客様のデータ センターに展開し、アプリケーション所有者の俊敏性と生産性、IT の柔軟性と管理、および企業資産の保護を提供します。

Azure Stackを使うと、Public CloudのAzureのような機能をPrivate Cloudでも実現できるらしいです。
このAzure Stack Technical Preview(POC)のHW requirementが出てました。

Technical Preview(POC)なので今後変更になる可能性がありますが、気になるのはStorage considerationsです。
・Data disk drive configuration:
 全データドライブは同じタイプ(SAS/SATA)・同じ容量でなければいけない。SASドライブの場合、single pathで接続されていなければならない(MPIO, multi-pathのサポートは提供されない)
・HBA configuration options:
 1. Simple HBA
 2. RAID HBA, Adapterはpass-through modeで構成
 3. RAID HBA, AdapterはRAID-0構成(Single Disk)
・Supported bus and media type combinations:
 - SATA HDD
 - SAS HDD
 - RAID HDD
 - RAID SSD(*)
 - SATA SSD + SATA HDD(3HDD以上)
 - SAS SSD + SAS HDD(3HDD以上)
(*) pass-through capabilityを持たないRAID controllerは、media typeを認識できない。そのようなcontrollerはHDDとSSDをUnspecifiedとするので、Azure Stack POCをデプロイできる

どこかで見たような構成だなと思ったのですが、Open Computeで公開されているMicrosoftのサーバデザインでした。
Microsoftのサーバデザインには以下のものが含まれています。
・Open CloudServer OCS Blade:
 CPUの載っている0.5U Blade。4HDD + 4SSDをサポート。
・Open Cloud Server JBOD
 HDDの載っている0.5U Blade。10HDDをサポート。
このOCS BladeとServer JBODのデザインにあっているように見えます。大規模に展開されているであろうサーバと要件があってそうとなると、期待が高まりますね。Windows Server 2016でサポートされるStorage Space Directなどと合わせてRAID装置なしでクラウドが実現できる時代が来てしまうんでしょうか。

何か面白そうなのでとりあげてみました。
また関連した話題があればお知らせします。(おそらくAzure Stackを試してみたという記事で)

ちなみに、なんでこんな記事を書いているかというと、本当はAzure Stackの前身となるAzure Packの実験環境を作って記事を書こうと思っていましたが書けなくなったからです。
記事を書くのを放置してたら、自動更新onにしてたせい?でソフトウェアのバージョンが合わなくなって?環境が駄目になりました(調査・復旧中ですorz)
みなさんちゃんと実験環境は自動更新offにしたり、snapshotとったりしましょう。

それではみなさま、よいお年をー

12/28 18:00 Supported bus and media type combinationsのところを修正しました。修正後: SAS SSD + SAS HDD(3HDD以上), 修正前: SAS SSD + SATA HDD(3HDD以上)

p.s. 怪盗レッドおもしろいですね。

CDN, イベント, インフラ全般, クラウド, ネットワーク

弥生のみぎり、皆様にはいかがお過ごしでしょうか。ホワイトデーも間近だというのに悩みがないのが悩みな初心者ツチノコです。 さて、本日は APRICOT 2015 という国際会議で DMM.com ラボとして発表をしてきましたので、そのお話を書いてみます。

APRICOT とは “Asia Pacific Regional Internet Conference on Operational Technologies” の略で長ーいですが、要するにアジア太平洋地域のインターネットに関する運用と技術について議論する国際カンファレンスです。

今回発表したのは “Traffic in Japan” という JANOG が担当するパネルセッションで、コンテンツプロバイダのトラフィックの傾向をお話して来ました。その他にもインターネットマルチフィードの吉田さんが日本全体のトラフィック、IIJ の松崎さんがトランジット ISP のトラフィック、QTNet の忽那さんが地域 ISP のトラフィック、ソフトバンクの平井さんがモバイルを持っているキャリアのトラフィックという形で発表されていました。近々、JANOG のページ http://www.janog.gr.jp/http://www.janog.gr.jp/meeting/index.html から辿れる形で公開されるとおもいますので、そちらもご覧くださいませ。

DMM.com ラボの資料は先行してこちらにおいておきます。( 版権が絡む様な画像は抜いてあるのでちょっと味気ないかも… )

 

さて、肝心のトラフィック傾向ですが、やはり我々のものは ISP の皆さんとは傾向が違いました。かくいう私も元々トランジットISPの出身で、2月に DMM.com ラボに入社したばっかりの超新人なので調査中から驚くことばかりでした。

特筆すべきはトラフィックの種類。通常トラフィックというと、ISP の人間は外部接続回線のトラフィックの合計みたいなものをまず意識します。DMM.com の場合もちろんそれも存在するのですが、他にもトラフィックソースが存在するわけですね。

弊社では以下の様なトラフィックソースの使い分けをしています。

まずは、自社でサーバ、ネットワーク、データセンタを運用しているオンプレミストラフィック。これが真っ先にコンテンツプロバイダのトラフィックとして想像されるものではないかと思います。DMM.com の場合、こちらには認証情報や各種APIサーバ、あとは動画、画像系のコンテンツが置かれています。とにかく定常的に大量のトラフィックが発生するトラフィックソースです。

次に CDN。こちらは Akamai さんに代表される様な CDN 事業者さんにオフロードしているトラフィックです。弊社では複数の事業者を利用しています。使い方としては、ライブイベント配信の様な事前に予測される一時的なトラフィックのオフロードの他、オンプレミストラフィックのうち急激に使用量が増えた人気コンテンツを移動する場合もあります。これは自動で出来れば大変にかっこいいのですが、今はまだ職人的運用者が「エイッ」って手動で移しています。

最後に、パブリッククラウドプロバイダの利用です。こちらは世界で一番メジャーと思われるあそこ、国内のあそことあそことあそこ、の様にたくさんの業者を使っています。こいつは主にオンラインゲームのトラフィックが乗っています。ゲームの開発元である SAP さんごとに、好みの環境というかクラウドサービスがあるので、ゲームごとに SAP さんに合わせて DMM.com ラボが契約する形です。この場合、お客さんがブラウザからアクセスすると、最初はオンプレミス上にある認証システムやトップ画面にアクセスした後、実際のゲームデータはどこかのパブリッククラウド上にいくわけですね。興味がある人はパケットを眺めてみるとあのゲームがどこにあるなんていうのは分かるかも知れませんね。

各トラフィックの傾向や比率については、前掲の資料をご覧くださいませ。

本当は帯域 だけではなく、同時接続数や単位時間あたりのセッション数でそれぞれのトラフィック傾向を語れるとよかったのですが、今回は時間がなかったり、各トラフィックソース毎に記録している情報の種類や粒度が違ったりで、残念ながら細かい比較ができませんでした。今後は是非、ここらへんも視覚化してみたいですね。

それではまた。

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