以前技術ブログ兼備忘録を書いてたんですが、引っ越しを機にすっかり書かなくなったので、こちらにて心機一転書いてみることにしました。タイトルは釣りっぽいですが、僕が社内で少し憂いていることを赤裸々に書かせていただくことにしました。
僕は渋谷で働くインフラエンジニアとして今の会社に入社しましたが、今はとあるプロジェクトのDevOps兼社内AWSソリューションアーキテクト的なことをやっています。DevOpsというジャンルは仕事が多岐にわたって且つ、割りと1人でできることも多くて、しかもすごい人達の助言をもらいながらも一定量の裁量権を得られる素敵な職業です。(厳密にはDevOpsエンジニアってのはおかしいって議論はここではやめておきましょう。まぁ、最近の一般的なDevOpsエンジニアという意味にしておいてください)
最近はhubotでdeployしたり、jenkinsのremote job叩いたりするようなコードを書かせてもらったり、"Deploy時間を10分以内にする"みたいな無理難題をみんなで議論しながら、さてどうしたものかと奮闘したりしています(ここいらの話はまま、よくあるといいますか、よく出る話だと思うので違うエントリーでかければ良いなぁと思っています。)。あとは、AWSコストをいかに抑えていけるかという課題に頭を悩まさせられたりしています。
一昔まえから、Imutable Infrastructureや冪等性のあるみたいな言葉が流行り出しました。言葉の意味は非常にたくさんの人がインターネットの海に書いてくれてるので、ここでは深く語るのはやめましょう。僕の見解は状態を持たない、壊そうが作ろうが、副作用のないInfrastructureです。
いきなり結論から言いますが、僕が言いたいのはこの一言です。
IP Addressを知らなくてはならないという状態は既に状態を持っていることにほかならない。
もちろん、他にもたくさん言いたいことはありますが、まずはこれです。といいますのも、僕は社内のConfluence(´Д｀|||)にて予約IPアドレス一覧っという表を見て大変驚愕しました。IPアドレスなんて、OpenStackなりAWSなりに勝手に採番してもらえばいいんじゃないの??APIで取って来るのってそんなに大変なんすかねぇっと。。。物理サーバならまだしも、OpenStackの上に乗った仮想サーバですよ??(僕がいる部署はプロジェクトによってAWSのところと、社内オンプレとしてOpenStackのところがあります。)僕はこの事態を非常に憂れています。例えば少しdirtyなshellですが、僕達のプロジェクトは
ssh LDAPユーザ名@$(aws ec2 describe-instances --instance-ids i-xxxxxxxx \
--query 'Reservations[0].Instances[0].NetworkInterfaces[0].PrivateIpAddresses[0].Association.PublicIp' \
--output text)(長いので改行しますた)とか、
ssh LDAPユーザ名@$(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)とかでsshログインしたりします。もちろん、このshellが特別きれいなものだとは思っていませんが、IP Addressが手動で管理されているとなかなかこうはいかないです。.。o○(この環境のどれか一台でいいから適当なサーバに入りたい)みたいなことって結構多いと思うんですよね。なのでそういう時はふたつ目のコマンド、ひとつ目はどちらかと言うと障害対応時だったりします(障害通知はinstance-idが飛んでくる)。まぁ、これは一例ですけど、ほとんどパラメータの変化しないchefのrecipeとか書いてる暇があったら(だいたいそういうところは、chefのrecipeにIP Addressの一覧みたいなのが書いてある(´Д｀|||))、インフラアーキテクチャ(適当な言葉が思いつかないれす)を設計しましょうよ。冪等性を追求するより、毎回サーバぶっ壊しましょうよ。既存の運用がーとかいろいろあると思うんで、せめてhubotに話しかけるとIP Address教えてくれるとかでもいいと思うので。。。(ちょっとhubot推し)
みたいな仕事をしていた時代もありました＼(^o^)／っがやはりこういう仕事はもう駄目かもしれないです。これやってて思ったんですけど作業者感ぱないです。なんとか(半)自動化したいなぁと思っていたわけです。やり方はいくつかあると思いますが、AWSにもOpenStackにもUserData的なものがあります(まぁ、わかりやすく言えばkickstartとかanacondaみたいな)。Jenkinsからぽちぽちするとchefの実行をUserDataにぶち込んでInstanceを立ち上げればよい。まぁ、やり方はどうでもいいんですけど、もっとみんながCreativeになれるとよいなぁと思う次第です。ちなみに、僕たちはすごいエンジニアさん(僕達のチームにネ申がいて、いつもおせわになってます。ちょいちょいこのブログにも登場すると思います)の助言により、chefもansibleもpappetもやめました。完全オンプレだとなかなかそこまでやりづらいかもですけど、僕はやめていいと思います。
Fluentの中の人(間違ってたら嫌なのでたぶん中の人と言っておきます=3)が昔なんかの勉強会でFluentはログ転送ツール、ログとデータは別物だよって言ってました。これはとても偉大な言葉だと僕は思っています。あくまでログ転送を行うマイクロバッチなんです。話がそれそうですが、僕が言いたいのはFluent使うとアプリケーションのプロセス落としてバッファが吐けるまでサーバ壊せないよってことです。Fluentのバッファのご機嫌をうかがう=サーバが状態を持っている、っということが言いたいです。ご参考までにですが(別に聞いてねえよって??すいません)、僕たちはいわゆるFluentが取り扱うようなデータ(よくログとか言われる)、例えば僕達の収益に影響がありそうなところはサーバにHTTPアクセスが来たらその流れでKinesisのAPIを呼び出してデータを突っ込んでます(僕が実装したかのようにほざいていますが、もちろんネ申がやってくれました。)。
いろいろ偉そうに言わせていただきましたが、既存の運用がーとかいろいろあると思うのでどれも思い通りにいかないこともあると思います。でも、お客さんしちゃうと結局中で何が行われているのかわからなくなっちゃうので、どういう意図があってそういう運用になったのかとか、楽にサーバを管理するにはどうしもんかなとか、ビジネスの動きにも耳を傾けつつ、そういうことを常々考えながらやってるとDevOpsもなかなか奥が深くておもしろいわけであります。僕が考える理想のDevOps(何かのプロダクトの中にいる人はって感じですが)は、サーバサイドのみなみなさまにサーバを意識しないようなインフラ、仕組みを提供する。そんな人に私はなりたい。
最後まで読んでくれた人本当にありがとうございました。