先月、日本で初開催された DevOps カンファレンスは、大盛り上がりでした。DevOps カンファレンスでは、それぞれの会社の中で複数人がチームがうえでどのような開発・運用体制をとっているかに主な焦点があたっていました。

しかし、中には小規模サービスを行っている人の中では、ほとんど一人で開発・運用を行っている人も少なくないでしょう。僕もそんな一人なのですが、個人的に一人で DevOps するために心懸けていることをいくつか紹介したいと思います。

「その場限りの実装を（できる限り）しない！」

ウェブサービスを開発している中で、よくあるのはその場限りの実装をしてしまうことです。もちろん、スケジュール・納期がありますし、一人が実装できる内容には当然ながら限りがあります。しかしながら、その場限りの実装をしてしまうと、そのあと問題になることがとても多いです。例えば、そのあとのウェブサービス改善の実装をしたとき、過去に行ったその場限りの実装が問題になってしまって、結局過去の実装をし直すことがあります。個人的には、けっこうこの体験が多いため、結局のところその場限りの実装をしてしまったことで、余計な時間を使ってしまうことになります。さらに過去の実装内容は、忘れていることも多いため、あのときどんな意図でこんなその場限りの実装したのか自分自身が実装しても思い出せないことがあります^^

ということで、個人的にはできる限りその場限りの実装はしないように心懸けています。もちろん、その分実装に時間がかかってしまいますが、将来に渡っての時間を考えれば時間のロスは減らせるはずです。

「他の担当者のことを考えて実装しているか？」

ウェブサービスである以上、ウェブサービスが成長していくのは当然のことです。サービスが成長していけば、当然ながらそのサービスに携わる人も増えてきます。それまで実装してきたのは自分一人で、さらにレビューも一人だった状況から一変するわけですから、他の担当者が一緒に実装することは想定しないで実装することがほとんとだと思います。しかし、ウェブサービスであるという特性上、一人でずっと実装していくことはほとんどないと思います。ウェブサービスが成長しなければウェブサービスを終了する、成長すればさらにウェブサービスを拡大させるため人的アサインを増やす、このどちらの選択肢になると個人的には思っています。

さらにネガティブな思考で一人でウェブサービスを実装しても成長することはないですから、ポジティブな思考で「今、この実装方法なら、他の担当者がみても変なくせなどがない実装だろうか？」と考えるようにしています。人に見られても恥ずかしくない実装を心懸けたいものです。

「重要な処理には、必ずログを出力する」

ウェブサービスの中で、例えば課金にかかわるなどの特にビジネスの面で重要な処理では、必ずログを出力するようにしています。これは、あとから問い合わせがあった場合にログがないと問い合わせに回答できないことになります。その他重要な処理以外でも、プログラムのエラーログ（スタックトレースなど）もちゃんとログを出して少なくても過去1ヶ月くらい分は保存しています。もちろん、プログラムのエラーが発生した場合は、その都度メールを送ったり、IRC などで通知してすぐに対応できるようにしています。

「運用側のセットアップが楽になるように心懸ける」

なるべく、インストールがめんどくさいライブラリなどはウェブサービスで使えるのは控えるようにしています。どうしても使いたい場合は、インストール手順をまとめて運用側の自分自身と共有するようにしています。このインストール手順は、運用側が別の担当者になったときも有益なものになります。

最近、Rails を使うことが多いですが、gem のライブラリをたくさん使うことがあります。その場合には、Bundler を使ってプログラム側でどの gem のライブラリのバージョンはいくつといった情報を実装側でまとめておきます。運用側は、Bundler の設定ファイルによって gem をインストールするだけになるので、運用側で gem の RPM を作らなくてよいなど運用側の手間も減らせるという大きなメリットもあります。具体的にどんな感じでデプロイしているかは、別の機会にエントリしたいと思います。

「なるべく一般的なシステムを使う」

実装側でも運用側でもそうですが、なるべく一般的なシステムを使うようにしています。一般的とは、きっと多くの人が使ったことがある、精通したことがあることを指します。例えば、Rails は、登場以来かなりの人気のある Ruby のフレームワークとなっているようです、もちろん他のフレームワークも人気のあるものがありますが、おそらく今もっとも多くの人が使ったことがあるフレームワークだと思います。そのようなフレームワークを採用しておけば、他の人にも「Rails を使っていますのでよろしくお願いします^^」と共有もしやすいです。例えば、もし自分自身オリジナルのフレームワークを使っていることを想像すると、きっと他の人が携わるのは難しいかもしれませんよね。

運用側ではいえば、例えばオペレーティングシステムの選択肢、サーバ向けのオペレーティングシステムには数多くのものがありますが、Linux を使うのがもっとも一般的で、さらに数多くある Linux のディストリビューションを何するか、自作のディストリビューションでも作るのかといったことが考えれます。僕は、今のところ最近不安だという声がちらちら聞こえる「CentOS」を使っていますが、「CentOS」を使っている理由は、おそらく Linux を使ったことがある人の中で一番多く使われているディストリビューションは RedHat 系だろうと思ったからです。もちろん、RedHat 系以外の Linux でもいいと思いますが、僕が選択する基準はそのシステムは一般的かという面に重点をおいています。もし、この基準がなければ僕は問答無用で一番昔から使っている FreeBSD を使いますけど、FreeBSD をインストールして使ったことがある人はきっと Linux をインストールして使ったことがある人よりかなり少ないと想像します^^。

「そのアーキテクチャーは、DevOps のどちらか極端に負担がかからないものか？」

ウェブサービスを開始するにあたって、ウェブサービスを構成するアーキテクチャーは、Dev / Ops のどちらに大きな負担を強いられるものではないかと事前に検証しています。自分一人だと苦労することは同じだと思いがちですが、自分自身の中で DevOps を Dev / Ops をしっかりと線引きして、そのアーキテクチャーは Dev つまり実装する側が面倒なアーキテクチャーではないか、また Ops つまり運用する側が面倒なアーキテクチャーではないか、をまるで自分自身を二つに分割して考えるようにしています。一番の理想は DevOps どちらにもバランスがよく負担がかかるアーキテクチャーになっていることです。最初からなかなかそのアーキテクチャーの選択が難しい場合は、だんだんとその理想の姿にあわせていくようにしたらいいと思います。自分一人でやっていると全部自分なので、さらに手間が増えますが、実装側、運用側、の効率をよくすることはウェブサービスの開発サイクルをさらに早くすることにつながります。

「しっかりと念入りにテストする」

当然ながら実装したあとのテストもすべて自分自身で行うことになります。自分の実装には自信があってバグなどないなどと思ったら正直負けです。その自信は端に置いておいて、テストするときもまるで別の自分になって念入りにテストするようにしましょう。特にウェブサービスの場合、本番で動いているデータベースでないと再現しないバグなどもありますので、本番データベースが使える場面ではあれば本番データベースを使ったプログラムだけは開発環境でテストするようにしています。本番データベースを使うことができない場合は、本番データベースをダンプした他の開発環境でテストするようにしましょう。自分自身で実装したローカル環境だけでテストしてリリースすることはあり得ない行為です。

今のところ、こんなことを意識しながら、とあるウェブサービスの開発・運用を行っています。

ウェブサービスに携わるすべての人、使っていただいている人、みんなが幸せになるそんなウェブサービスを目指すしていきたいですね。

Tags: devops

先週の金曜日の出来事になってしまうけれど、DevOps カンファレンス #1 に行って来た。
主催者の @marqs さん、発表者の @mizzy さん、@marqs さん、@kuwa_tw さん、@hiroshi19790209 さん、@riywo さん、講演ありがとうございました！！！

mizzy さんによる DevOps 入門、から始まり、それぞれ所属されている組織内での DevOps のやり方、個人手金は現在一人 DevOps している身として、とても参考になりました。
それぞれの発表者の資料は、@marps さんのブログにまとまっていると思うので、それちを参考にしてもらうとして、DevOps カンファレンス #1 を振り返って個人的な感想を書いてみたいと思います。

まず、DevOps 的な内容として、前職の思い出が思い出されます。当時は、いわゆるスタートアップで、世界中の人たちのたくさんの人々に使ってもらうことを目標にしてさまざまなウェブサービスを作っており、おもに Dev 側（プログラマー面）、Ops 側（インフラ面）、両方の立場で業務をするという貴重な体験をしました。

まず最初に僕が携わったのは、世界デビューを目前としているとある写真共有サービスでした。当時、そこでは次のような内容で、ウェブサービスの改良を行っていました。

• ウェブサービスの改良をするエンジニアがいる
• インフラを担当するインフラエンジニア一人がいる
• それらを統括するマネージャ兼 CTO がいる
• 週一回、バグトラックシステムを使い、CTO が今週やることをアサインする（当然ながら会社としての方向を兼ね合いもあります）
• エンジニアが実装した内容を確認する、QA エンジニア 1 名がおり、エンジニアが実装した内容を開発環境で徹底的にテストして確認する、QA エンジニアが  OK しないものに関しては本番環境へリリースしない（本番環境のデータベースなどが必用であれば、開発環境に個人情報をつぶした形で十分なデータベースを用意して、QA エンジニアにテストしていただく）
• インフラ面で改善する場合には、事前にメンテナンスのスケジューリングをして、必用な場面であれば QA エンジニアにメンテナンス中にテストしてもらう、問題がないようであればリリースする

当時であれば、スタートアップという場面では、非常に優秀なエンジニア、QA エンジニア、がいるという、今思い返すと、とても恵まれている環境でした。

ここでの DevOps 的な役割は、次のような感じで暗黙な感じになっていました。

• プログラマーは、ウェブサービスの改善・改良にひたすら専念する
• QA エンジニアは、プログラマーの実装した内容をできる限りで本番環境に近い形でテストして、問題がなければ QA エンジニア自身が rsync などで本番環境にリリースする
• インフラエンジニアは、トラフィックなどを監視して必須な改善を実施する、アーキテクチャーに大きな変更を伴うときには、CTO / CEO に対して情報共有を行い、その改善が必須かどうか判断して実施する、大きなアーキテクチャーの改善を伴うときにはメンテナンス時に QA エンジニアにも待機してもらいテストしてもらう

僕は、このときプログラマー、インフラエンジニア、の両方の担当になりました。当然ながら、時期はずれています^^

このとき大きな失敗をしたのかどちらのか、お分かりでしょうか？当然ながら、インフラエンジニアのときに大きな失敗をしました。。。。このときのことは今も貴重な体験となっており、忘れもしません。当時は写真共有サービスのため、ストレージの増強（つまり、当時はより大容量のものにハードディスクを入れ替える作業）を僕が担当したときのことです。。。

このときに大きな失敗をしました。具体的には、次のような前提条件になります。

• 当時は、active / backup タイプの DRBD + NFS（NFS は大人の事情でトラフィックを分散させる目的で写真へのアクセスを分散させるだけの目的で使用していました） で、ストレージを組んでおり、一台のストレージが落ちてしまうと一部の写真全てにアクセスできなくなる可能性があること
• 写真の枚数は、rsync すると差分の計算だけで半日程度かかってしまうが、メンテナンス直前までサービスを影響のない範囲で rsync を繰り返し実行していた

ここで、スケジューリングしたメンテナンス時刻になりました。

僕は、QA エンジニアに待機してもらいながら、次の作業を実施しました。

• サービスをメンテナンス状態にしてもらう、写真をアップロードできないように、念のためサービスもメンテナンス状態にした（当然ながら、特定の社内ネットワークからののみ、mod_rewrite を駆使してアクセスな可能な状態にした）
• メンテナンス設定後、データの追加がなくなったことを確認して、最後の rsync を実施した（これについても時間がかかるため、想定の時間もメンテナンス時間に含まれています）

rsync 後、念のため wc -l ですべての写真の数を確認して、QA エンジニアに一通りのサービスを確認してもらったあと、サービスをメンテナンス状態から解除しました。

。。。

しばらく問題がなかったので、僕と QA エンジニアは帰宅して休むことにしました（徹夜作業だったため）。

僕が休もうとした直前、CTO から電話がきました！！！

CTO から、昔貼り付けた写真のブログにおいて、その写真が閲覧できないことを確認したという連絡でした。

その連絡を受けて、僕は飛び起きて、その対象となるブログ（そのときは CTO 自身の個人ブログの昔の記事）を閲覧したところ、確かにストレージを組み替えてから写真が 404 になっていました。。。。

その原因は、アーキテクチャーの抜本的な理由により、昔貼り付けられた写真については閲覧できないデメリットがある前提のもと（PV がほとんどないため、mod_rewite ルールによる互換性の問題）、アーキテクチャーの変更をしたのが理由であったのですが、CTO/CEO/QA エンジニア に対してしっかりと Ops 側（インフラ側）が情報共有をしていないために大きな失敗をしました。。。当時は、僕の責任なので誤る言葉もありません。。。申し訳ありません。。。

このときは、Dev/Opts という二つの役割は違う人にあったことも大きいですが、Ops 側のアーキテクチャーを変更する上でのメリット・デメリット、を正確に Dev に共有できなかったが大きな失敗を生んでしまった原因であったと今も反省しています。

DevOps カンファレンスでは、それぞれの会社が置かれている状況やそれまでの運用形態により、各社さまざまな運用形態があり、それに相応する歴史があり、その歴史に対応するべき対策があったりと、同じウェブ業界でもこんなにも違うものなのかを感じたカンファレンスでもありました。

現在、僕は小規模のサービスを一人で DevOps している環境にしていますので、えらそうなことはまったくいえないのですが、とても重要な一つのポリシーをして、次のことがいえると思います。

その対策をして、Dev / Ops / ユーザ / みんな、そのウェブサービスに対して幸せになることができるか？？？

本当にみんなその対策で幸せになるのでしょうか？その対策で不幸せになる人はいないでしょうか？もしいるとすると、その人は不幸せになることを伝えて納得をもらっていますか？？？納得をもらえなら、その対策は絶対にすべきではないです。なぜなら、あとで必ず絶対にそして近い将来、とても困る場面があるからです。

技術的なことでも、必ずメリット・デメリットが伴うことが多いと思います。技術的なら、デメリットに対してメリットを許容するべき内容であるのか、デメリットはメリットを超えてみんなを不幸にしないのか、そんなことが考えられます

対象となるウェブサービスの性質、信頼性、などを考えると、一概に答えが出る問題では当然ながらないので、自分がかかわっているウェブサービスに対して、例えインフラエンジニアの担当だったとしても、僕が俺が私がこのウェブサービスを支えているいるんだ、これが僕が俺が私が担当しているサービスで、一番仕事の中で重要なウェブサービスであると、当事者意識を持ち続けることが大切なんだと思います。

個人的な過去の体験を振り返ると、Dev 側のみであったことは、正直当事者意識はすこし薄くなってしまったと反省しています、反面 Ops 側になった瞬間当事者意識はかなり大きくなった（PC を肌身離さずようになった！）と思います。これはかなり調子のいい例だと思いますが、Dev でも Ops でも、同じレベルの当事者意識をもつカルチャーを作ることが DevOps なカルチャーを作る、そんな材料の一つになっているかもしれないと感じた DevOps カンファレンス #1 でした。

個人的には、ほぼ一人 DevOps している人が少ないかもしれないで、#2 で機会があればほぼ一人 DevOps につて話したいと思います！

Tags: devops