自動化がーとか、immutableでーとか、冪等性がーとか、chefがーとか、fluentがーとか、よく聞きますがDevOps兼インフラエンジニアとしてのぼくが思うところを書いてみようと思います。でも、こういう話って一昔前にありましたよねぇ。もっと早く書いておけばよかた。
一昔前から、Imutable Infrastructureみたいな言葉が流行り出しました(逆に最近はあんまし言われない。みんな自分なりの答えを見つけたんやろか)。ぼくはImutableとは状態を持たない、すなわちいつでも壊せて、いつでも建てれて、それでサービス影響が(もっと言えばビジネス損益が)ないということだと思っています。
そんなとき、ぼくは社内のConfluence(´Д｀|||)に、予約IPアドレス一覧という表を見て驚愕しました。。。IPアドレスなんて、KVMとかVirtualBoxじゃないんやから、OpenStackとかAWSとかに勝手に採番してもらえばいいんじゃないの??
人間がIP Adressを知らなくてはならないってのは状態を持っているということだ
ぼくが言いたいのはこれだけです。chefだろうがansibleだろうが、サーバを立てたら自動的に構成管理ツールが走るみたいなのはいいんかもしれませんけど、そんなことはどうでもいいんです。IP Addressを知るとか、、、冗談きついです。なので、ぼくたちの環境には(ぼくたちはAWSユーザです)踏み台サーバ(笑)とかありませんし、Elastic IP Addressもひとつも使っていません。例えば、ぼくたちが障害対応でサーバにログインするときは、
ssh USERNAME@$(aws ec2 describe-instances --instance-ids i-xxxxxxxx \
--query 'Reservations[0].Instances[0].NetworkInterfaces[0].PrivateIpAddresses[0].Association.PublicIp' \
--output text)とか
ssh USERNAME@$(aws ec2 describe-instances \
--filters "Name=tag:elasticbeanstalk:environment-name,Values=production-blue" \
--query 'Reservations[0].Instances[0].NetworkInterfaces[0].PrivateIpAddresses[0].Association.PublicIp' \
--output text)
みたいにインスタンスIDとか、tag名で指定してログインします。前者のケースはほとんどなくって(前者のケースでは特定の1台を指定するわけですが、hubot氏に聞いてInstance IDの一覧をもらったり、障害通知でInstance IDが飛んできたりします。)、後者みたいにログインすることが多いです。状況としては障害が起こるのって1台のサーバっていうよりは1環境みたいなことが多いと思うんですよね、だからその環境のサーバの中から適当に1台にログインするみたいな。
冪等性を仮に何度ながしても変わらないchefのrecipeということにしましょう。でもそれって結構たいへんです。ifこれが指定されていたらhogehoge.confの中身は変更せずに、else hogehoge.confを作成するみたいな。
ぼくは冪等性反対派閥です。冪等性など持たずに、サーバは毎回壊せば良い。たとえばぼくたちはBlue Green Deploymentというものをしていますが、deployの時には毎回対象の環境のサーバが全台新しくなっています。わかりやすく言えばTerminateです。(苦労して運用してきた秒間15000リクエストのシステムを支えるBlue Green Deploymentについては別の機会にブログしようと思います。)なので、サーバはアプリケーションが動く器くらいに思ったほうが気が楽だなとおもいます。
ぼくたちは初期の頃、ansibleを使おうかという話が盛り上がっていました。でもansibleに触れてみると、リモートシェルがyamlで書ける(いや、悪気はないんですよ！ぼくがansible詳しくないだけだと思うので、ほんますいません)みたいなもんかとか思って少しため息でした。そんななか、チームのネ申が、_Dockerfile一枚でいんじゃないですかねぇ_という助言をしてくれて、ぼくたちは、冪等性という魔物から開放されることになりました。サーバぶっ壊し運用最高！ただ、このへんの話には少し裏ワザもあって、ElasticBeanstalkの.ebextensionsというものを使っているシーンもあります(Docker + ElasticBeanstalkがぼくたちのデファクトスタンダードです)。ElasticBeanstalkを1年間運用してみてについては、別のブログで語ることにしましょう。
冪等性をやめると構成管理はすごいすっきりするし、Dockerコンテナ以外の部分は、UserDataで(オンプレならanacondaとかkickstartつかえばいい)ぶち込めばいいと思います。
flentd、いいと思います！ぼくたちはどのサーバにも入っていませんがｗ 以前なんかの勉強会でfluentの中の人(たぶん、たぶんですよ汗)が、fluentdはログ転送を行うマイクロバッチデーモンですとおっしゃってました。そう、マイクロバッチなんですよね。
また、別の偉い人が、ログとデータは別物、取り扱いは十分に考えてやったほうがいいともおっしゃってました。すごい！！
なんか違う話になっちゃいそうですが、ぼくが言いたいことは、Fluent使うとバッファーがはけ切ってプロセスが落ちるまでサーバ壊せないよってことです。Fluentのバッファーのご機嫌を伺う=サーバが状態を持っているってことです。だから、この1台だけ調子悪いなってときも速攻terminateぽちーとかできないんです。(LBから切り離して、Fluentのバッファーの中身確認してとかだるすぎる！！！しかもその間に1時間経ったらお金もかかる)
しかし、これは別の視点から見れば、fluentに転送させているのが単なるログであればたかだか何件かロストしたところで特に問題はないということだとも思います。なので、ぼくたちはHTTPリクエストの都度、データをkinesisに突っ込んでいます(kinesisに書き込むデータもバッファリングしません)。ログは、これまたElasticBeanstalkのlogging機能を使ってS3にアップロードしてもらってます(アップロード中にサーバが死のうが問題はない)。
まとめるとこんな感じでしょうか、IPアドレスからの脱却(tagで管理しろ)、冪等性の棄却(いちいちchef書いて80番がリッスンしてるか確かめるとかだるすぎる)、データはデータ、ログはログみたいな。サーバをいかに気兼ねなく壊せるようにしておくかというのが、運用負荷の軽減と事故防止、ひいては安眠につながると思います。我らがプロダクトマネージャーが言ってましたが、インフラは必要性に駆られていろんなものを作っていくけどそのひとつひとつにセンスがないとエクセレントにならないと。
既存の環境がーとかいろいろとあるとは思いますが、エクセレントなインフラを作って、もっとCreativeな仕事をしていきましょう。長々とありがとうございました。