「文殊概論/３：文殊の技術的構成」の編集履歴（バックアップ）一覧に戻る
文殊概論/３：文殊の技術的構成 - (2008/11/06 (木) 21:54:13) のソース
§３ 文殊の技術的構成と運用サイクル 文殊はある意味「CGI」アプリケーションとも言えます。しかし、皆さんが想像する「CGI」という言葉の印象（掲示板とかチャットとか）とは随分隔たりもあるでしょう。そして、黒埼がほぼ一人で文殊を開発・運用し続けている事を、随分と凄い事のように思う方もいるようです。 これには、ちゃんと仕掛けがあります。わかってる人にはしっかりバレてる程度のものです。 それでは、文殊開発と運用の裏側について、しばらくアイドレスから離れ、技術的側面から説明していきましょう。 ** 文殊の運用 図（＊）は文殊のシステムを、バックアップまで含めて示したものです。 ・Webサーバ・maki.wanwan-empire.net：海外の業者である"RailsPlayground" と年間契約したサーバーを使っています。ドメイン名は私が別途取得したものを使い、これを業者のサーバの別名として適用しています。 ・管理サーバ：私の自宅で常時動かしているサーバでWeb非公開。maki.wanwan-empire.net の死活監視とバックアップデータの定期取得を行っています。バックアップは１時間毎の１世代バックアップと、毎日の無制限世代バックアップの両方で行っています。 ・バックアップ保管所：http://www.geocities.jp/cw7_mirror/monju_backup/index.html 文殊のバックアップデータを保管しているWebサイトです。Geocitiesの無料アカウントを使っていますが、50メガバイトの要領制限がきついため、ちょくちょく過去のデータを手で消しながら使っています。（なんとかしたい・・・） ・ソースコードレポジトリ：文殊の開発用ソースコードを保持するサーバです。自宅の外において公開しているため、共同開発者のｏｄさんもアクセス・変更を加える事ができます。また、文殊を１から再構築する必要があった場合でも、このレポジトリにあるソースコードとバックアップ保管所のデータさえあれば可能です。 まあ、Ｗｅｂサーバのみを「文殊」と見なしてもいいのですが、運用系全体となるとこれくらいになります。 **バックアップデータを公開する理由 私がこうして各世代のバックアップデータをわざわざ公開していることには、理由があります。文殊管理人による不正なデータ改ざんを抑止するためです。 現状、文殊管理人は文殊に対し、全てのデータを改竄できてしまいます。編集履歴すら自由に捏造できるのです。（いや、しませんけどね？） 文殊を管理する人員がアイドレスのプレイヤー以外であるなら、まだこれでもいいのでしょうが、私もまたアイドレスプレイヤーの一員であり、利害関係者です。 本来、これは健全な管理方法とは言えません。 しかし、「文殊管理人がデータを自由に変更できないことを保証する」のは困難です。文殊は私一人が管理しているので、どうとでも誤魔化せてしまうからです。しかし、私以外の管理者を入れる事は、技術的・保安的にとにかく面倒です（不可能ではないのでしょうが・・・）。 そこで私は、「複数人の管理人がお互いを監視し続ける」複雑さを採用する代わりに、「過去のバックアップデータを常に公開し続ける」ことで、「過去にさかのぼってデータを改竄したと疑われる」可能性を極限しました。こうやって公開していれば、誰かがある時点でこれらをダウンロードする可能性が発生し、その可能性は私の改竄を抑止するのです。 これは、文殊の扱うデータが全て公開できる性質のものだからこそ、取れる手段と言えます。閲覧するユーザに応じて隠すべきデータがあった場合、バックアップデータの公開という手段は使えません。 ＃自分でも少々偏執的かなと、思う事もあります **サーバーダウンへの対処 文殊は稀に、いや時々、サーバーが止まってしまうことがあります。（ご迷惑をおかけしております） 理由としてはバグの場合と過負荷が原因です。 バグによる停止は黒埼のうっかりが原因です。黒埼が原因なだけに、わりと簡単に抜本的対策が取れます。 過負荷による停止の場合、問題は厄介です。 文殊が利用しているサーバは共用サーバといって、１台のサーバを複数の利用者が同時に使っています。（おそらく数十人レベル）このため、他のユーザがWebサーバを酷使するような使い方をしている場合、私には対処方法がないのです。他のユーザの常識的運用を期待するほかありません。 もちろん、一人で占有できるサーバを契約すれば解決するのですが……高いのです。私の財布ではちょっと厳しい。しょうがないので、「止まったらサーバ管理者に連絡して直す」とするしかありません。 最近文殊が止まる度、私は英語でメール書いてます。めんどい。 **死活監視:Nagios こうなるともう、「止まったらすぐ連絡」する監視体制が必要です。このため、最近になって「Nagios」を導入しました。現状、私の自宅のNagiosは文殊へ２分毎にアクセスし、その動作を確認しています。アクセス不能な事態が起きたら私の携帯メールへ知らせる仕組みにしています。 このおかげで、深刻なサーバ障害にも即応できるようになりました。しかし、平日昼間に止まってしまった場合、夜になるまでどうしようもなかったりします。その時はすみません。本気ですみません。 **文殊開発の切り札：Ruby on Rails 今度は運用から、開発の実際を説明していきましょう。 文殊は Ruby on Rails を使って開発しています。Ruby on Railsとは「Web アプリケーションフレームワーク」です。Ruby on Railsを知らない人は、とりあえず「Webアプリを作るための基盤、骨組み」くらいに思ってください。 文殊の開発効率（一人でこれだけ作り上げる）の高さは、全てこのRuby on Rails が達成していると言っても過言ではないでしょう。Ruby on Rails には基本的なプログラムコードを自動生成してしまう"Scaffold"生成機能があり、私は殆どこのままの状態で文殊の機能を利用しているのです。 （文殊の画面構成がひたすら地味なのは、そのせいでもあります） これだけは言えます。Ruby on Rails が使えなければ、私はそもそも文殊を作ろうとすら思わなかったでしょう。 「Ruby on Rails が何者か」については、良質な参考文献がたくさんありますので、この場ではそれらを紹介するに留めておきます。 **コードリポジトリ：Subversion Ruby on Railsを使って書いたコードはテストされ、テストが通るとSubversionリポジトリに登録されます。Subversionには過去の登録履歴が全て登録されており、その度に変更点と変更事由も一緒に記録されます。変なバグが入り込んでも、いつどんな理由でそれが入り込んだのか追跡し、その波及範囲についてもしっかり管理できます。バグは一匹見つけたら２０匹、ゴキブリみたいなもんです。こうしてしっかり追跡できるように手はずを整えるのは大事です。 Subversionリポジトリを用意することで、共同開発者のｏｄさんも文殊のコードを改変することができます。文殊は一人で開発を始めましたが、いずれ一人では開発しきれなくなる事も想定していました。そのため、こうして最初から共同開発できる仕組みだけは、整えていたのです。 **デプロイ：Capistrano Subversionにコードを登録した後、Webサーバにこれをアップロードしなければなりません。通常のCGIプログラムならFTPなりを使えばそれで済むのですが、私はここでCapistranoというツールを使っています。Capistranoは以下の手順をコマンド一発でやってくれます。 １）サーバの一時停止 ２）別ディレクトリを作って、最新版プログラムをアップロード ３）Webサーバが最新版プログラムを利用するよう、リンクの張替え ４）サーバプロセスの再起動 ２）の手順によって、（上書きでなく）別ディレクトリに必ずコードを展開するため、「本番サーバにデプロイしてみたら動かなかった」場合でも、即座に前バージョンに戻すことができます。 私が実際にデプロイする場合は、本番サーバと同じデータベースを使いつつ、別URLとなる「リハーサル環境」にまずアップロードして、動作チェックをする事にしています。ここで引っかかるようならテスト・デバッグへ差し戻し。その間、文殊を停止する事はありません。 **問題追跡システム：Mantis （途中） **黒埼の日常 では、典型的な黒埼のタスクについて、例を挙げて説明していきましょう。 ・日中昼間：Nagiosから障害メールが届く。見てみると"Socket Timeout on 10 seconds"、文殊が１０秒以内に応答しなかった、との連絡。この場合はとりあえず放置。２分後に”Recovery"通知がくるようなら、緊急対処は必要なし。 "500 Internal Server Error"だったら頭を抱える。可能なら昼休みに職場から対処し、それも無理ならとにかく残業回避に全力を注ぐ。 ・仕事退けてメシ・フロなど済ませてから、メッセを起動。金庫番の人からオフラインメッセージなどが来ていない事を確認し、文殊の開発をはじめる。 ・文殊の開発案件について確認、コーディング、テスト。簡単なものなら１時間程度、難しいものでも１機能で２・３日かかりきれれば大体終わる。 ・レポジトリへの登録と文殊へのデプロイ。それぞれコマンド一発。 ・金庫番から苦情：「なんか文殊の様子がおかしーですー！」黒埼の顔が青ざめる一瞬。事情を聞き取った後、文殊のサーバへSSHログイン。動作ログを見てエラーを特定。 ・デバッグ対応：ログをみれば、大概の原因は一発で判明するので、これを直して再アップデート。同じ条件で現象が再現しないことを確認し、金庫番へ更新を連絡。そちらでも現象再発なしを確認してもらって障害対処終了。 ・Mantisに記録：バグと修正の内容、および対処に時間を記録する。本当は障害発生時点から記録すべきだが、大抵はバグ修正への速さを優先して後回しにしている。 黒埼が文殊の開発において、各種の開発支援ツールを使っている様子がお分かりいただけたかと思います。 ＃書いてて思ったが、私が対応不可能な場合は越前さんにやってもらう事も考えた方がいいかもなあ……。
