読者です 読者をやめる 読者になる 読者になる

Line 1: Error: Invalid Blog('by Esehara' )

または私は如何にして心配するのを止めてバグを愛するようになったか

>> Zanmemo

あと何かあれは 「esehara あっと じーめーる」 か @esehara まで

スタートアップでインフラを見てまわって感じた、初歩的なアンチパターンについて

はじめに

 今、いわゆるWebサービス系のベンチャーのお手伝いをしている。基本的に、自分の役割としてはサーバーサイドのプログラマであるのだけれども、こういうベンチャーの常として、インフラ担当だとか、サーバーサイド担当だとかいう明確な区別をしない、あるいは出来るほど人がいなかったりする。自分のところもそうで、結果として過去にWebサービスをデプロイしていた経験と、普段使っている愛用のOSがUbuntuであるという部分から、結果として障害があったりした場合に、インフラを見ることになる。

 とはいえ、最初から完璧なインフラは存在しない。例えばWebサービスを作るために勢いで作ったインフラがそのまま放置されていたり、あるいは、最初は考えられたインフラ構成であったとしても、だんだんとそれが足かせになったり、あるいは考え方によっては、もっとインフラのコストをさげて、プログラミングに集中できる可能性がある。

 そこで、今回のブログ記事は「あー、これちょっとつらかったなー」というパターンを少しだけメモしておこうと思う。ちなみにこの記事の前提は、AWSを利用し、またインフラエンジニアと呼ばれるほどの択一した人が存在しないということを前提としている。したがって、本当にインフラを集中している人にとっては当たり前のことが多く含まれている可能性が高いけれども、こういう当たり前のことはなされてないので、あえてそういう記事になる。基盤システムや大規模システムになると、まだ違うパターンがあると思うので、それはご愛嬌で。

 もっとアドバンスな話については、下の本とかを読むといいんじゃないんでしょうか。

 あと、下のAWSのアンチパターンとかも参考になりました。

属人性・アンチパターン

ストーリー

 当然、サーバーに負荷がかかると、突然サーバーが落ちたりするなどの問題が起きたりする。例えば、あるサービスは深夜にアクセスが集中する。あるとき、深夜にサービスが落ちてしまった。できるだけ早く復旧させたいと思うものの、しかし、その復旧の仕方は、ある人にしかわからない。その人に連絡を取ってみるものの、捕まえることができない。その人が起きたのは朝である。深夜の間、サービスはメンテナンス状態になっていた。

問題

 よほど複雑な構成であったり、技術的なミッションでない限り、対応できるエンジニアがいるならば、その人が復旧に当たれるほうがよい。また、その人が体調不良などの関係で捕まえることができなくなった場合、そのこと自体がネックになる可能性がある。少なくとも、多くの人が何らかの障害に対して調査できるような体制であることが望ましい。

対策

 ベンチャー立ち上げ時だったりすると、自分一人がサービス構成を把握しておけばよいとなりがちになり、サーバーを構築するにあたっての手順を残さなかったりする。サーバーを構築するにあたっての手順があるだけでも、そのアプリが何によって支えられているかが把握できるし便利だ。もちろん、決まった手順があれば、それを書き残しておく。しかし、これらの手順は、どうしても手作業でやらないといけない部分があるならば、全てを何らかのスクリプトにして残しておくほうがいいと思う。

見落とし多発・アンチパターン

ストーリー

 あるとき、急にサービスがアクセス不可能になった。サーバーを復旧するにあたって手順書が公開されていたので、それを見ながら復旧をしていた。しかし、本人は手順通りに作業したつもりなのだが、しかしサービスにおいて、つなげない場所が発生した。もう一度手順を確認してみると、見落とししているところが存在した。確認してみると、そういうことが何回かあった。

問題

 サーバーを復旧させるときに、手順の見落としが発生することにより、サービスが健全に動いているかどうかわからない。

対策

 人間がやることは必ず見落としがある。なので、できることならダブルチェックが望ましいように感じる。また、できることなら、スクリプトによる自動化を行う。また、サービスのステータスをすべて確認できるような画面を用意する必要がある。

ノー・ウォッチ・アンチパターン

ストーリー

 Webサービスがどんどんスケールしていき、順調に利用するユーザーも増えてきた。しかし、その中でいきなりサービスが動かなくなってしまった。サーバーの中に入ってみると、メモリのリソースを食いつぶしていた。今回はAWSであったので、インスタンスのサイズを変更して対応したが、しかしそのインスタンスを変更するのにも時間がかかってしまった。

問題

 サーバーのリソース監視ができていないことによって、いつリソースがなくなるのか分かりにくい。リソースがいつなくなるかわからないことにより、その対応が遅れてしまう。また、リソースの調査も出来なくなってしまう。

対策

 サーバーのリソースに関して、ネックになる部分(CPU、メモリ、容量)はちゃんと記録しておく。また、それらをグラフティカルなツールによって見れるようにすると、リソースの使われ方の流れが目に見えるようにする。また、それらのリソースに対して、何らかの閾値を超えたり、あるいはそれよりも下がった場合、何らかのリマインドがされるように設定する。

ファット・サービス・アンチパターン

ストーリー

 Webサービスの障害対応をしていたところ、いろいろとデーモンが立ち上がっていて、それを一つずつ確認するのは手間がかかっている。また、一つ一つに対しても、チューニングが追いついておらず、上手くそれらのインフラを活用できていないし、またそれらの情報を集めるだけの時間もない。開発者同士で相談したところ、それらを使わなくてもうまく使うことができるようなので、使うものを整理することで、以前よりも、それらの設定に注力できるようになった。

問題

 人材のリソースがないときに、そのWebサービスのコア価値を支えるわけではないのにも関わらず、インフラにおいてメンテナンスするものが増えてしまう。もちろん、インフラに選任できる人がいればそれが問題ではないかもしれないが、本当に注力したい部分に対して、労力が費やされてしまう。

対策

 ほかの解決策がないか調べること。本当に外せないもの(メインのデータベースなど)で代価できないかどうかを考えること。Webアプリケーションが動いている中で、ソースコードをリファクタリングする中で、本当は使わなくてもいいものではないか考えること。クラウド上で動いているとするならば、それらを利用してできないかどうかを考える。クラウドの場合、本来だったらそのクラウド上に存在しているサービスを利用することによって、コストが削減できる可能性がある。

開発環境全部入りアンチパターン

ストーリー

 Webサービスを作成するときに、開発中のアプリケーションを公開しておく必要があった。そこで、一つのサーバーにアプリケーションをすべて入れて、サーバーで動かしていた。しかし開発上のアプリケーションがいろいろと動いているために、アプリケーションの設定を切り分けるのが大変だった。さらにいうと、設定は設定で本番からやるので、ぐちゃぐちゃになってしまう。

問題

 開発用のサーバーと本番のサーバーが合わせることができないため、本番は本番で独自の設定をしなければならない。また、新しいアプリケーションを開発するたびに、新しい設定を継ぎ足しせざるをえない。

対策

 厳密にいうと問題であるのかという話はあるのだが、しかし現状としてDockerなどの仮想環境で切り分けることを考えたほうが、設定がきれいに分かれるので便利になるのではないかな、という印象。また、設定自体をスクリプトとして記述しておくことで、開発中の設定を、本番に利用することができるし、また環境もコンパクトになりやすい。AWSならインスタンスを分けるのも有効であるように感じる。インスタンスの構築結果をイメージに残しておくことで、そのまま本番環境にすることができる。

まとめ

 自分の中途半端に何でも見ているエンジニアからすると、インフラを本当に考えなくていけないのは、アプリ側でチューニングしなければいけないことだったり気がする。しかし、基本的にそういうときというのはそんなに早くはやってくるわけではない。むしろ、インフラを整備することに手間をかけたり、エンジニアが消耗して、本来開発に集中したい部分に集中できることができなければ意味がない。

 基本的な方針としては、ChefやAnsibleといったような(そして、もちろんこれらのサーバー構成ツールこそがコストになる可能性があるので、天秤にかけなければならないのだが)スクリプトを作りながら、人間がやらなきゃいけない領域を減らし、機械でできる領域を増やすことにつきると思う。例えば、何らかの手順がスクリプトにできるならそのほうがいい。

 また、採用される技術に関しても、出来るだけ減らしたほうがいい……というと、ChefとかAnsibleなどと関わっているかもしれないけど、基本的に技術の採用としては、それをかけたコストに対して、満足できるほどのリターンが帰ってくるのか、といった部分は適切に判断しないといけない。そうしないとエンジニアは消耗するし、それで消耗してサービス開発に注力できないとするなら、まわりまわって運用や経営の動きも鈍る。

 正直、インフラのリファクタリングをどうするのか、というかどうしたいのかという話というのは、もっとしたいというか、されてほしいなと感じます。特に自分なんかはひよっこなので。