23日に、弊社代表の上原が主催しているRTCカンファレンス福岡verが開催されたようです。

学生によい刺激をいただいた！ | イベント | チェケラッ！ | あすなろBLOG 

 

23日に北九州市立大学で行なわれた「ＲＴＣカンファレンス福岡ｖｅｒ」に参加してきた。

参加の立場的には協賛企業としてだが、今回の会を取り仕切ったのは北九州市立大学、九州大学の学生。彼らとは昨年10月に福岡で行なったRTCカンファレンスで 出会い、その懇親会で「次回は僕らがやります」と言っていた、懇親会の場で冗談半分だと思っていたら、彼らは本気であり・・・そして開催までこぎつけたの ある。パネラーも自分達で交渉したとの事、なかなかやりますねぇ。。カンファレンスも非常にいい感じで終わり、私もよい刺激をいただいた。

 

RTCカンファレンス 北九州Ver.　後録 ｜ 近江商人JINBLOG

 

前回福岡でRTCを開催した折に参加していた北九州大と九州大の学生たちが「九州ではこういう場がほとんどないから、またやってくださいよ」というような話をしてくれて、その時に「いーねー。でもわざわざ俺たちにやらせることないよ。自分らでやりなよ。やる時は協力するでー」というようなことをちょうさんと言ってたのです。

すると半月後くらいにその学生たちから「九州RTCプロジェクト発足しました！1月に開催しますので来てくださいね！」という連絡が来ました。まじかいな、でもほんとにやり切れるんかな、と思ったりしていたのですが、はい、見事にやり切ってしまってくれましたね。 

 

今、弊社でインターンとして活躍してくれている学生さんも実行委員のメンバーでしたし、私の後輩にあたる若い人たちが頑張っているのはとても嬉しい事です。

私が学生の頃はちょうどビットバレーなどが盛り上がっていた頃でしたが、九州からみると、東京で起こっている出来事は海の向こうのアメリカで起こっているのとあまり変わらないように思えてしまっていました。なので、地方で何か行動を起こす！というパワーが集まったということはすごいです。

カンファレンスの実行委員の1人が九州大学で所属している九州大学ベンチャー・ビジネス・ラボラトリーでの講義の件である。

 

 そういえば、私もベンチャービジネスラボの講義を受講していました。懐かしいです。新規ビジネスとして、高齢化社会にITを活用する案をいろいろ考えていましたね。

これだけネットが普及している時代です。地方だからといっても何のハンデもありません。地方の学生がんばれ！

こちらでお知らせしていた第7回エンジニア交流勉強会「gungi」を開催しました。

 今回は、オープンソースなConfiguration management system であるPuppetについて、その時代背景から使い方の初歩までを、FreeBSDのPuppetメンテナーである櫻井さんにご説明いただきました。

IT業界のエンジニアのうち、やはりアプリケーションプログラミングに従事されている方が多く、OSやシステム管理が出来る方というのはなかなかみつかりませんね。大手サイトを運営している企業でも、サーバ／インフラエンジニアは常に募集しているようですし。

 そのような人手不足の中、大量のサーバ（しかもOSや役割が異なる。。）を維持管理するには、極力自動化する事がミソになってくるわけですね。

恥ずかしながら、Puppetを昨年のSoftware Designの記事で初めて知り、現在勉強中でしたので、今日の説明は非常に為になりましたのでメモ。

＝＝＝＝ 

Configuration Management

OSのインストールは自動化(PXE Boot /sysinstall/kickstart)されているか？
OSインストール後の設定作業を自動化できているか？
いつ誰が何をどういう風に設定変更したかを把握／管理できているか 

 

cfengineとは

設定の一見管理を行うツール。
管理パターンを定義する。例えば、ファイル操作や、daemon操作、パッケージ管理等。
設定手順等をSubversion等で一括管理する事が可能。
使い捨てのシェルスクリプト、perlスクリプトを書かずに済むようになった。
管理作業がパターン化・品質の均一化ができ、作業漏れ等が無くなった。

反面
ソフトウェアとしての進化が止まっていた．
作業手順の依存関係や関連性、継承などに制限があった。
などの問題点があったとのこと。

Puppet

このような背景から、cfengineの課題を解決する物としてPuppetが登場！
拡張性、依存関係などをきっちりと記述可能であることや、ログ／監査が可能であることは特徴的です。

セキュリティ

多くのマシンに確実にセキュリティポリシーを適用するには、設定を自動化すること。手作業では漏れが必ず発生する。仮に侵入されたとしたら、OSを再インストール、再設定が必要になるが、これも自動化すること。でないと、手順書に基づいた設定が本当にきちんとなされていない可能性がある。

まとめ

自動化により、ミスが入る余地を減らせる。（人間のやることには必ずミスがある）
品質の向上にもつながる。
 

＝＝＝＝

さて、まだまだ改善すべきところはたくさんあります（汗）

その後、フォートラベルの山路さんと私による、「Web屋のシステム管理」と題したショートコントセッションの時間を頂戴いたしました。

月間3,500万PVのトラフィックを40台のサーバで捌くシステムを、昨年末までお一人で管理していたとの事で、貴重なお話をお聞きする事ができました。

＝＝＝＝ 

Q1.サーバ台数の割りにエンジニア少ないんですけど、自動化している工夫があればおしえてください。
A1.障害発生時に自動復旧するような構成、スクリプトなどを用意している。LVSなども自動復旧のために活用している。夜に電話やメールで起こされないように（涙）

Q2.では逆に、自動化できていない泣き所（今後自動化したいところ）はありますか？
A2.サーバの追加作業等。まさにPuppetをこれから検討しようとしていたところ。今年の終わりくらいには、サーバが200台になりそうなので、サーバ追加の工数も無視できない。大規模サイトはどうやっているのか知りたい。

Q3.障害対策だけじゃなく、負荷対策でも自動化などしていますか？
A3.クローラ(bot)対策の工夫をしている。百度のクローラによる負荷が激しかったので、mod_proxyを使って、クローラだけ別サーバに逃がしたりしていた。

また、CDN(Contents Delivery Network)によりネットワーク帯域の負荷対策などを行っている。一時期、韓国の掲示板に大量にフォートラベル内の写真(１枚数MB)を貼られてしまい、その掲示板からのトラフィックで、通常の10倍の帯域(300Mbps弱)を使っていた。CDNを採用していなかったら、おそらくサイトが落ちていたのでは？

Q4.最後に。ドラえもんに1つだけお願いできるとしたら、どんなシステム管理用ツール・機器をおねがいしますか？
A4. （山路さんが）不在の時に限って障害が発生するので、どこでもドアが欲しい(笑)。それが無理ならコピーロボット、ってそれはパーマンだ(笑)

じゃ、タイムマシン。過去に誤った設定を行っている自分のところに行って注意をしたり、未来に行って、成長しているメンバーを一時的に連れてきたりしたい。

＝＝＝

最後に、櫻井様よりOpenBSDについてのご紹介がありました。

こちらはNetBSDからフォーク（分岐、分裂？）した時のエピソードや、自前でドライバ開発をする経緯など、面白おかしくご紹介いただきました。

そういえば、私が初めて触ったのはUnix系OSは*BSDでした。（もう10年以上前になりますが。。）

最近は商用アプリケーションを使う必要が無いので、よくよく考えてみたら*BSDでも問題無いんですよね。久しぶりに使ってみようと思います。

今回のgungiは、すこしニッチなテーマに絞ってみましたが、予想に反して盛り上がった会となりました。
登壇頂いた櫻井さん、山路さん、参加された皆様、ありがとうございました。

次回もお楽しみにしてください。