ネットワーク事業部の事業部長をしている嶋田健作です。

ネットワーク事業部では、データセンターサービス「データホテル」を中心とした法人向けの各種サービス・事業を行っております。今年は、クラウドやソーシャル関連などが盛り上がっておりますので、我々も縁の下の力持ちとして、新しい取り組みをして盛り上げていきたいと思います！よろしくお願い致します！

さて、何か技術的なことを書こうかと思いましたが、他にすばらしいエンジニアがたくさんいるので、ちょっと一風変わって最近凝っている「外出ハック（？）」を書きます。

外出しよう！〜 外出に持って行くもの

エンジニアの人も客先に行ったり、セミナーや勉強会にいったり、よく外出する人もいますよね。私はちょっと前まではパソコンを持ち歩いていたのですが、年のせい（？）か重く感じ始め、コンセントや電波を求めて街をさまようのが悲しくなってきてしまいました。そして、最近だとアナログツール＋iPhoneでいいやというように割り切りはじめました。そんな訳で、ふと外出する時にエンジニアとして「持って行くもの」にクローズアップして書こうと思います。

私が普段持ち歩いているものは、

1. アナログツール〜 ボールペン・メモ帳・クリアフォルダ・クリップ
2. デジタルツール〜 iPhone・携帯電話

です。その他たまに持ち歩くものとしては、障害対応セット（シリアルケーブル、ケーブルチェッカー、工具など）も面白い（？）かと思いますが、今回は、客先とかセミナーに行くときに普段持ち歩いているものを紹介します。

■1. アナログツール〜ボールペン・メモ帳・クリアフォルダ・クリップ

紙とボールペンの優れたところは、
・電池切れがない
・書き方自由！
の２点につきるかと思います。

○多色ボールペンとメモ帳

やはりメモをとる時や図で説明する時には、カラーである方が表現性は高まります。最近だとボールペンでもたくさんの色があるものもありますが、やはり太いと鞄に入れた時や、メモ帳に挟んだ時にかさばるのが気になります。また、ボールペンというのは私は不思議なほどよくなくすので、4色程度のある程度安価なものを選んでいます。

というわけで、最近だとZeblaの「クリップ-オン スリム 4C」というのを使っています。

次にメモ帳は、マルマンのMNEMOSYNE（ニーモシネ)シリーズの「NOTE PAD　［ノートパッド＋ホルダー］」というやつをメインで使っています。

5mm方眼罫のシンプルなやつなのですが、ノートの上部に「DATE/No.」と「TITLE」と二つのカラムがあり、キレイに内容を書き始められます。方眼罫は、何かネットワーク図を書くときにでも、アイディアを書くときにでも、非常に便利です。また、各ページにミシン目が入っているので切り取って、メモを誰かに渡したり、スキャナで読み取っちゃって保存という時でも便利です。

また、このノートパッドのすてきなところは縦開きということです。横開きの場合だと、机を挟んで何か打ち合わせする時に左のページに何か書いてあると相手も気になっちゃいますし、気を使って次のページにとんで、振り返ってみるとなんか右側が白いページが続くと、もったいない気分になっちゃいます。好きなだけ新しく書いて、切り離して、読み込んで捨てる、という使い方をするのが良いかと思います。

ちなみにディスカッションに行くときは、同じシリーズのIMAGINATIONというA4サイズのものを持ち歩いて、好きなだけ自由に書いて、スキャナで読み込んで後で考えることにしてます。

○クリアフォルダ・クリップ

これは外出した時にもらった資料や、持っていった資料などをまとめるのに使います。クリアフォルダに各種資料を仕分けして、最後に複数をクリップで留めてしまいます。まさに、実物の「フォルダ」です。多色のクリアフォルダが分別にも便利で使っています。

ところで、捨てて良いものかどうか悩む資料ってありますよね。私は「悩み箱」という段ボールに放り込んでいって、おそらく二度と見ないだろう決心がついたら、段ボールごと捨ててしまっています。私のようにものを捨てれない人にはお勧めです。

■2. デジタルツール〜 iPhone・携帯電話

実はiPhoneじゃなくても良いかもしれませんが、最近だとiPhoneを使ってます。

持ち歩くデジタルツールの主な使い方は大きくわけて、
・メール、スケジュール、TODOをみる
・情報を収集する
という２つの使い方をしています。アナログツールと違うことは、「今、この瞬間の情報を調べる」ということです。

○メール、スケジュール・TODO・メモをみる
これは普通に会社のスケジューラなど使っています。たぶん、多くの人は、Googleカレンダーやグループウェアを利用されていると思うので、iPhoneや携帯経由で自社で使っているものなどを使うのがよいかと思います。スケジューラやTODO管理に関するハックは世の中にたくさんあるかと思いますので、そちらをごらんになっていただければと思いますが、何をするにせよ「一つのものを使い続ける」ということが効率化のポイントだと思って心がけています。

○フィードで情報収集
手前味噌ですが、私はlivedoor Readerを使って、ちょっとした移動時間や空き時間で情報収集しています。

各種技術サイトの情報や、気になるエンジニアや会社のブログ、営業の人なら、リリース情報や倒産情報などのフィードを登録しておくと、移動中などのちょっと空いた時間で情報収集できるかと思います。気になる情報は、「ピン」を立てておいて、会社に戻ってゆっくりみることにしてます。気になるものはガンガン登録し、興味のないものは読み飛ばし、気になったものだけ拾うという使い方をしています。

○ネットワークに関する情報収集
私がよく使うものとしては、Whoisでドメイン名を調べたり、ping打ったりとこの仕事独特の情報をみることがあります。気休めにターミナル系のアプリも入っていますが、さすがにiPhoneは文字が打ちづらいので何か作業をすることはしません。iPhoneを使うのは、このように携帯電話だとやりづらいような「ミニパソコン」的な使い方をしているせいかもしれません。

iPhoneはいろんなアプリがたくさんあるので、twitterでつぶやいたり、何か調べ物するにも便利ですよね。
今年は、Androidも頑張りそうな予感もするので、もっと便利なデバイスやサービスが出てくるのが楽しみです。

■最後に
というわけで、勝手に私の鞄の中を紹介させてもらいました。他のエンジニアに何を持ってるいていますか？と聞くと、ネットブックやブロックメモや付箋紙、書籍、ネットワーク診断ツールなどを持ち歩いている人などもいますよね。

いろんなデバイスやネットのサービスが多くでてきて本当に便利になってきましたが、その時々で仕事のやり方や持ち物も変わってくると思います。そんな中で我々も、お客様や業界の方の仕事を効率化するようなサービスメニューを、アナログな部分にもこだわって作っていけたらと思います。

それでは今年もよろしくお願い致します。

こんにちは。あけましておめでとうございます。ライブドア技術部会の伊勢幸一です。本年もライブドア、並びにこのTechブログをよろしくお願いします。

このTechブログはもともとlivedoorポータルの開発スタッフ有志によって運営されておりましたが、昨年2009年6月から技術部会が運営を引き継ぎ、ライブドアの全技術職社員がエントリを担当するようになりました。そこで、そもそもライブドア技術部会とはなんぞや？という事からお話します。

現ライブドアは2007年に旧ライブドア(現LDH)からlivedoorポータル部門とデータセンタ部門が独立し、設立された新会社です。それまでライブドアでは事業部制を敷いており各事業部は独立採算で、今現在でもその独立採算事業部制を踏襲しています。従って、たとえ同じライブドア社内であったとしても事業部同士で互いのリソースやサービスを利用するにはそれぞれ対価を支払うという関係です。今までポータルとデータセンタ間には社内同士であっても明確な責任分解(分界)点が設定されていました。事業やITサービスにはこの責任分解点を適正に設定する事は大変重要なのですが、逆に分解点の向こう側に対しては無関心、無責任になりがちになるという弊害もあります。

ライブドアの特徴はWebサービスにおけるマネタイズコントロール、サービスの開発と運営、そしてサーバシステムの運用とインターネット接続、トラフィックエンジニアリングまでを社内部門だけで賄えるという事です。すなわち最終的なサービスマネタイズに要求される性能と品質を、どのような技術、運用で実現するのが最適なのかを一緒に考えられる環境にあります。しかしながら実際には複数の部門に跨った技術的課題を複数部門間で整理調整、そして合意し、供に最適化を図るという事はなかなか難しい作業です。そこで、逆に新生ライブドアでは、マネタイズコントロールからトラフィックエンジニアリングまでという全レイヤにおける一貫した最適化とシナジー効果を実現する事が唯一競争力の源であるという結論に至ったのです。

たとえば、コンテンツを配信する場合、ネットワーク運用担当者がコンテンツの特徴、つまり萌え系なのか社会問題系なのか、PV/UUとマネタイズの関係はどうなのか、どれくらいのコストでどれほどの配信品質を維持するべきなのかを分析した上で、ピークかアベレージか、トランジットかピアリングか、コンシューマ向け回線でもいいのかという事を検討し、どのnext hopへ流すかを判断します。コンテンツ特性を考慮しないトラフィックエンジニアリングにあまり意味はありません。

また、システムとして配信ノードは分散可能なのか、分散すべきなのか、同一VLAN上で構築すべきなのか、遅延はどれくらいまであってもマネタイズに影響は無いのか、画面パーツフレームのどの部分には遅延が許されないのか、どの部分は遅延が許容されるのか、そのためのメモリ、ディスク、ネットワークインターフェースはどこにポイントを置くべきか。CPUクロックで実現するか、マルチコア化で対応するのかという検討を開発者とサーバ運用者が行うのでしょう。それぞれのマネタイズ事情とサービス特性を無視したシステム設計は無意味です。

そういう部門に跨る難しい技術的問題課に対処するため、新生ライブドア設立直後に結成されたのが技術部会です。
ちなみに、ライブドアの技術職ライン職制はこのようになっています。

執行役員
シニアマネージャ
マネージャ
グループリーダ
エンジニア/プログラマ

その他にスタッフ職制として以下があります。

シニアスペシャリスト
スペシャリスト
テクニカルディレクタ

現在のところこの技術部会は技術系執行役員、シニアマネージャ、シニアスペシャリストの9名とサービス部門から事業部長1名、事務局1名の11名で構成されています。

結成当初はそれこそサーバのセットアップ作業の情報伝達フローやメーリングリストの整理、ストレージの投入撤去、アカウント認証システムの入れ替え、新技術の調査検証など細かい問題を取り扱っていましたが、2年もすると部門間における誤認、不具合、わだかまりも解消し、問題課題等の議題はほぼ無くなりました。現在ではテクニカルセミナの主宰、Techブログの運営作業を主軸とし、技術トレンドなどの情報共有、社内BOFや勉強会の開催、技術職の育成教育問題などを手がけるようになって来ています。

昨年2009年は「livedoor」という社名が生まれてから10周年の年でした。また、今年2010年は「DATA HOTEL」というデータセンタが生まれてから10周年を迎えます。

そこで、そのダブル10周年を記念し、今月1月はこのTechブログでも技術系技術部会メンバ9名によるブログリレーを行う事となり、このエントリがそのブログリレーの第一走者です。これからのTechブログにも、ぜひご期待ください。

「メールって携帯じゃなくて？」と、いう状態で事務職として入社して3年。「サーバーって何？」と、いう状態でエンジニアになり2年半。常に無謀という名のチャレンジを続けてきましたライブドア6年目のbambiです。

テクニカルな話題とは打って変わって今回は私が勤めるデータセンターのサポート業務についてご紹介したいと思います。

「そもそもデータセンターってサーバーの再起動以外に何をしてるの？」

いえいえ、色々やることはあるんです。

ライブドアのデータセンターであるデータホテル(通称DH)は365日24時間フルマネージド型のサービスを提供しています。サーバーのハード障害はもとより、ミドルウェアの運用・障害対応サーバー構築や提案、お客様からの相談窓口など、多岐に渡ったサービスを休むことなく提供しています。

その第一窓口となるのが我がオペレーショングループです。

障害が発生したり、ホスティングのお客様から何かしらの依頼があった場合、まずは専用のデータベースに登録をします。一日に登録される件数は平日で120件を超過するくらいあります。しかし、それらは運用フローに組み込まれる起票件数であり、その他にもメールのやり取りだけで対応する場合や、電話での問い合わせのみの対応等々を含めると、1日に処理する対応件数は300件を超えています。

お客様やサービスによっては運用だけではなく、営業的なお話や別部署での対応になるものがありますので、適切な対応がなされるよう各部署へと振り分けを行ないます。でも、基本的には受け取る依頼の大半はオペレーショングループで対応します。お客様から電話で不具合の連絡を頂いて、話しながらサーバーの設定変更を行い、解決に至るというような対応もしばしばで、その対応力の早さもデータホテルの特徴です！　例えば、

「メールがすべて送信できなくなってしまった」

との連絡を貰い、話を聞いている中で、昨今プロバイダ等で導入されている「OP25B(Outbound Port25 Blocking)」では？と予想。

ホスティングしているサーバがお客様のメールサーバとして稼動している場合、お客様の加入しているISPのメールサーバ以外に25番ポートではアクセスできなくなるという問題です。すぐに、お客様の送信用SMTPサーバを25番ではなく、RFC2476で推奨されている587番ポートを立ち上げ、メーラー側のSMTPポートの設定を変更して頂き、問題解決！

なんてこともあれば、

「間違ってWEBのコンテンツを消してしまった」とのSOSを受け、別ディスクのバックアップからコピーして復旧！！などなど。また、大掛かりな移設作業などではお客様のサービスをダウンさせることのないよう綿密な計画を立てたうえで、スケジュール等のご提案を差し上げることもあります。

サービスが色々あればお客様も色々いらっしゃるわけで、お客様によってはかなり特色があるので、一律な対応は出来ません。厳格なお客様に気軽な言葉で話して怒られたこともありました。障害中のため、焦っていたこともありますが。あるとき、サーバのレスポンスが異常に遅くなり、お客様から電話で問い合わせを受け、調べてみたところ、サーバの負可が異常に上がっていたため、

「アクセスが集中して、サーバーの状態がかつかつで…」

と説明をしてしまったのですが、お客様の口調が急に冷たくなってしまった事もあります。おそらく「WEBへのアクセス過多によりサーバーリソースを使い切った状態となっております」なんて言葉が適切だったのでしょう。

○○様、あの時はごめんなさい。

この部署で第一に必要な力は「空気をよむ」ことなのでは…？と、思い始めた今日この頃。技術的なお話ではありませんでしたが、「あー頑張ってるんだー」と少しでも思っていただけたら幸いです。

どうも、はじめまして。DATAHOTELサービスでフルマネージドホスティングのオペレータをやらせて頂いておりますDO(ドゥー)といいます。

テックブログなるものではございますが、私が技術を語るなどとは... オペレータとして培ったこれまでの経験から、「まぁ難なく」という範囲内でひとつこの場をお借りして少しだけ語らせて頂ければ、と思っております。

マネージメント

「まぁ難なく」と言ったところで、まず私の業務内容の範囲がどれだけあるのかお話ししないといけませんよね。業務内容をひと言で言いますと、サーバのマネージメント。単にマネージメントと言いましても、その分野は多岐に亘りサーバのセットアップから始まり、プラットフォームやアプリケーションの構築やパラメータの調整、顧客の運用を手助けするための提案、また安定運用をご提供する為の監視、障害発生時の復旧作業など、様々な分野のマネージメントを行っているのです。

また障害発生時の復旧作業ひとつにおいても、障害発生箇所によってその対応内容は変わってきます。今回は障害がハードウェアで発生した際の復旧作業内容について少しだけお話させて頂きたいと思います。

Standard Server (標準機)

まずはハードウェアで大本となるサーバについてご説明を。一般の方などは見たこともなければ「サーバってビールの？」といった感覚...にはならないと思いますが、実際どの様なものかはわからないと思いますのでライブドアで使用しているサーバの中でも最もスタンダードな2機種のサーバを簡単にご紹介したいと思います。

<< IBM製 System x 3250 M2 >>



IBMと聞いてピンときた方も中にはいらっしゃるのではないでしょうか。そうです。ノートPCのThinkPadで有名なあのIBM社製のサーバです。Webサーバとしてもメールサーバとしても、もちろんDBサーバとしても使用可能なとても使い勝手の良い機種の一つです。

<< サン･マイクロシステムズ製 Sun Fire X4150 >>

こちらはサン･マイクロシステムズ社製のサーバ。前面にある8つの小窓がHDD搭載ドライブで、IBM社製のサーバよりも一段階スペックが高い機種となります。スタイリッシュなボディが格好良く、個人的にはxseries3250 M2よりこちらの方が好みだったりします。ただし総重量がかなり重いのが難点... 2009年後期の時点で、ライブドアデータホテルで一番推奨している機器になります。

どちらのサーバも長細く平たい形をしていますが、データセンターに設置してあるスタンダードなサーバは、大抵この様な形をしています。もちろん何倍もの厚さがあるサーバや皆さんがご自宅で使用しているデスクトップ型PCをサーバとして使用することもあります。

障害のカギ

さて、話は戻りましてサーバの障害について。やはり｢形あるものいつか壊れる」わけでありまして、時にうんともすんとも言わなくなる場合があります。そんな時はもちろんサービスは行えなくなっており、早急な復旧対応が必要とされます。

どこに問題が発生しているのか？
メモリなのかHDDなのか、それとも機器本体の問題なのか？
はたまたHDDと基盤を繋ぐコードの問題なのか・・・？

早急な対応を求められる私たちにとっては、この切り分けがカギとなります。

サーバからの...

そしてそのカギを握るのが、サーバから発せられたダイイングメッセージ。サーバがダウンする寸前に残してくれているこのメッセージはかなり重要で原因の切り分けには必要不可欠なものになります。例えば以下のメッセージ。


何やら英語と記号の羅列の様に見えるこのメッセージですが、内容を良く見ますと『hard error reading』の文言が。訳さなくとも何となく「読めない」と言う意味であることがわかりますよね。サーバで読み書きが行われているのはHDDになりますので、この場合はHDD障害であることが推測されます。

同様のメッセージで

こんなメッセージが出力されていることもあります。先ほどのメッセージより読解が困難ですが、"I/O"の意味がわかってしまえば一目瞭然。「I」はInput、「O」はOutputであり入出力を意味しています。そして「SCSI」というのがそもそもHDDの種類を表していますので、こちらもHDD関連の障害と推測されます。

HDD障害以外でのハードウェア障害を示すメッセージではこの様なものもあります。

『scsi』や『dead』と言った文言から推測するとHDD周りかと思いがちですが、こちらは xseries3250 M2独特のハードウェア不具合であり、現在IBM社による原因解明が進められています。ライブドアではエンジニアの検証により暫定対応としてファームウェアのアップデートで回避可能であることが判明していますが、この様な事態が発生しても、障害時には早急な復旧対応が必要とされます。

この他にも、メモリの障害であったりkernelやRAIDカードの不具合であったり、またアプリケーションによるswap領域の枯渇であったりと、様々なダイイングメッセージが出力されています。と言っても、発生する障害全てにおいて都合よくエラーメッセージが出力されている、ワケではないのですが...。

蘇生

何かしらのメッセージが残されていれば、例えばHDDエラーであればHDD交換を、メモリの不具合や認識不良であったら、メモリやサーバ自体の物理交換を、xseries3250 M2の様な独特の障害であれば、それに見合った対応方法を、と言うように、その障害に応じた蘇生法を実施しなくてはなりません。

時にはメッセージの出力が全くなく、切り分けや対応に時間を要してしまう場合もありますが、障害発生時は切り分けから完全復旧まで、より短い時間で最小限の被害に抑えられるよう最善の復旧対応を行う、といったマネージメントを行っています。

毎日がマネージメント

今回はハードウェア障害時のマネージメントについてお話しましたが、障害ひとつ取っても、アプリケーション周りの障害であったり、ネットワーク回線の障害であったりと様々な障害と向き合わなければなりません。また先にも述べているように、日々私たちは様々なマネージメントサービスを行っており顧客の求めるサービスレベルに一歩でも近づける様にマネージメントとは？と、自問自答しながら業務に励んでいます。サーバマネージメントに少しでも興味がある方は、是非「livedoor DATAHOTEL」サービスで一緒に頭を悩ませてみませんか？　また私たちオペレータに運用サービスを任せてみたい、というお客様はどしどしお問合せ頂けます様お願い致します。

データホテルへのお問合せはコチラ↓


他にもこんな人が働いています!!
スタッフの声
DATAHOTELのスタッフ紹介

こんにちは。オペレーショングループのイトウです。

24時間3交代制の職場で、データホテルにある数千台のサーバのお世話をしています。前職ではいわゆるホワイトボックスメーカーといいますか、PCやサーバを作る側の仕事をしていまして、ライブドアに転職してそれらを使う側の仕事をするようになりました。そんな経歴なので、ハードウェアの面から見たデータセンタの話を書いてみようかと思います。

1Uエントリーサーバ

データホテルにあるサーバで一番多いのは1Uサーバです。CPUは1サーバ当たり1個ですがシングルコア、デュアル、クアッドコアと3種類が混在しています。メモリはバンクが4スロットあり、そこにメモリモジュールが2枚、もしくは4枚インストールされています。HDDは2台ですが、通常RAID構成にはしません。

メーカーのラインナップで言うとエントリーサーバという一番安いクラスのものです。中にはもっと高性能なモデルもありますが、一番多い機種はこんな仕様です。メーカーからしてみるとこのクラスのサーバは価格勝負になりやすく、利益率が低いのであまりおいしい商品ではありません（笑）。

私も前職では5Uのサーバに物理CPUが8個、メモリは4GBx32本...なんてマシンを作ったりもしましたがそれとは対照的です。使う側からすると、ハードウェアは極力シンプルなもので台数を束ね、それをソフトの力で活用する、というのが理想的なようです。

RAID1 + バックアップ

HDDが2台のマシンでサーバを構築するとなると、オンボードのRAIDコントローラでRAID1を...と考えることが多いかと思いますが、RAIDは組まずに1台ずつ単独で使い、1台目をシステム+データ用、2台目をそのバックアップ用とすることが多いです。cronからrsyncを起動し、1日に1回フルバックアップ（同期）を取ります。

RAID1で耐障害性を上げるとはよく言われることですが、何かのトラブル（設定や操作上のミスも含む）でデータが失われた場合、RAIDでは2台のHDDから同時にデータが無くなります。しかしRAIDを組まずに一見原始的な日次バックアップとすることで、このような場合でも最悪前日分のバックアップから復旧することができます。

もう少しモデルのランクが上がってHDDが3台入るサーバの場合、ハード屋さん的な考えだと、1台のサーバにどれだけ大きいストレージを作成する事ができるかという方向に興味が行きがちで、3台以上ならRAID5でいいんじゃない？となります。

しかしデータホテルではHDDが3台ある場合、1台目と2台目でRAID1を組み、3台目にRAID1のバックアップを取る構成をとります。HDDが3台あるのに使える容量は1台分とかなり贅沢な使い方に見えますが、こうすることでRAID1のリアルタイムな冗長性を確保できますし、万が一のトラブルでデータが失われた場合でも、前述のようにバックアップディスクから少なくとも前日の状態に復旧することが可能です。

お金では買えないデータの保全を第一に考えた結果の使い方と言えると思います。

筐体交換

データホテルにあるサーバでハードウェアの障害が発生した場合、まずログなどからHDDが異常だと判断できればHDDを交換します。そうでない場合、どこが異常かすぐに判断できない場合はどうするか？この場合「筐体交換」と言って、HDD以外のサーバ本体全体を交換します。障害が発生したサーバからデータが入ったHDDを抜き、新しいサーバ本体を持ってきてHDDを取り付け電源ON、対応完了です。

注意すべき事として、筐体交換をすると、サーバのMACアドレスが変わってしまうので、データホテル標準としてOSインストール後、
/etc/sysconfig/network-script/ifcfg-eth*　
ファイルに自動的に記載されるMACアドレス部分を削除するというルールになっています。この対処によって、サービスのダウンタイムを最短にすることができるのです。また、前述のようにシンプルで同じ構成のサーバを大量に扱っているからこそ可能な対応です。ディスクが抜かれた筐体は別途、機材担当者が大まかに原因を調べ、メーカへ修理に出すか、故障部分の部品を交換することで対応します。

前職ではサーバが故障して戻ってくると、原因はマザーボードかメモリか、それとも電源か...などと時間をかけて切り分け作業を行ったものですが、サーバを使う側の立場に立つと、サービスの継続が最優先、データの保全が最優先、となり、対応方法も対照的になります。

こんなデータホテル、いかがでしょう？などと宣伝臭くなってきましたのでこの辺で...