仕事柄ありがたいことに、Web業界の中でもトップノッチな技術者の方とお話させていただく機会が多いのですが、そんな中で、”そう言えば、昔の自分ってどうだったっけな？”って開発現場にドップリ浸かっていた頃のことを色々思い出してきて、現場の人が享受できるコンテナ技術やマイクロサービスの利点ってなんだっけな？というところをメモしておきたいと思います。
開発チームの何でも屋的な役割
以前の職場では、大きい組織の中でアーキテクトとか開発リーダー的な役割でプロジェクトに携わったいたのですが、同じサービスの中でも常に複数の案件が動いているような状況で(まぁ、組織の大小に関わらずこういう状況はありますよね)、その中で↓のような事に非常に気を遣っていました。
・リリースブランチを切るタイミングとそこへのマージ
・結合テストを行う環境の準備とか(特にQAテストの一部をアウトソーシングしたりしてたので)
テストの後の方の工程に発覚したバグFixのマージとか、他の開発ブランチで発覚した機能そのもののバグFixのマージとか、バグFixとは言え混ぜるな危険みたいのとかあって、コミットログとか見ながらウーウーしてました。
でもって、そこがちゃんと修正されてるか〜とか、他のところがとばっちり食らってないか〜とかって観点でテストしていくわけですが、(もうだいぶ以前の話なのでアレですが…)当時はCapistranoを使ってデプロイ作業そのものは自動化していたけど、データベースのスキーマ変更とかミドルウェアのパラメータを変更したり、、みたいのが伴うと自分の作業だけで済まない(他部署への作業依頼とか…)ところがあったりして、胃がキリキリするような思いをしたり。。
もちろん環境依存になりそうなところは外部設定ファイルとか環境変数に外出しするようにレビューとかでコントロールはしていたけど、なんというか、諸々全体を見るって観点だと、自分が完全にシングルポイントで、性格上(？)あまりドキュメントを細かく残せるようなタイプでもなく、今考えるとあんまり健全な状態ではなかったのかもな、と。。
また、QA担当の人のアサインがｘ月ｘ日までで〜とか、テストはじめるのに環境構築がｘｘ時までに終わってないとｘｘ時までしか専有できないので〜、みたいなこともあったので、その為に環境構築をスクリプト化したり、SeleniumとかJmeterとか、事前にやれることは自動で、、というのは意識してたけど、そんなに簡単にホイホイとテストが進んでいくわけでもなく(大体ガッチャンコしてそれっぽい環境にデプロイすると何かが起こって、スタックトレースとにらめっこしてワチャワチャしてた)、その辺はたまたま、社内で顔が効くとか、コミュニケーション力とか、そういうので乗り切ってました。
そんなこんなでなんとか本番へのリリースっていうところまで辿り着くと、本番環境のデプロイや検証も自動化はしてたけど、その為の申請とか、切り戻り判定基準とか毎回考えたりしなきゃいけなかったり、何十台もあるサーバーが本当に全台大丈夫なのか？みたいのって、NFSサーバーに集まったログを全台分sedとawkでホゲホゲやって、なんというか正に”Undifferentiated Heavy Lifting(他社との差別化に繋がらない重労働)”だったよなぁ、と。とにかく本番環境で何か作業をすると申請して承認もらってみたいのが発生するので面倒くさかった思い出。。
自分がやりたかったこと
そもそも僕がやりたかったことは何だったのか？と。もちろんサービスを安定稼働させるというのはあるけど、サービスを使ってくれてるお客様のためになる機能を1つでも多く開発したくて、そのフィードバックが欲しくて、売上とか利益に貢献したくて、インターネットサービス企業でエンジニアをやってたはずなのに、気付けば、申請・調整オジサンになってた。
たまに社内で開催されるハッカソンの時とか、技術書の輪読会とかで張り切っちゃったりしてたのは、ひょっとしたら、英語の勉強も、そういうことに関する逃避行動みたいなところもあったりしたのかもしれない。
Twitterに要らんこと呟いたり、居酒屋で愚痴を並べ立てたり、なんかその頃のネガティブだった自分が今思うと勿体無いっていうか、文句ばっかり言ってないで自分がイニシアチブを取って自らドライブして改善していく組織やルール作りが出来れば良かったのかな、と。。
じゃあ、なんでDockerなのか？なんでマイクロサービスなのか？
こないだこんなブログポストを書いたり、仕事でお客様と会って話してる時に紹介させていただいたりするのですが、ココ最近で一番ガツンと来たのは↓のAWS Summit San FranciscoのNextdoorのプレゼンテーション。
[youtube https://www.youtube.com/watch?v=fqXa0RKJvJE&w=560&h=315]
僕が開発現場にいた当時Dockerは無かったけど、マイクロサービス的な考え方はあったわけで、それぞれが小さいコードベースで機能間の依存を疎にできれば、胃がキリキリするようなリリースが減って、どんどんアイデアを形にして出していこうぜ！とかっていう雰囲気に出来たかもしれないし、そのリズム感を出すためにビルドやデプロイの時間を短縮しようぜ！みたいなノリに出来たかもしれない。
↓のスライドでも紹介したことあるけど、AWSの根底ある思想として、”Undifferentiated Heavy Liftingの排除”というのがあって(コレは2006年のWeb2.0カンファレンスでジェフ・ベゾスが語った内容)、ソレって我々ITエンジニアがよりクリエイティブなところにフォーカス出来るように！ということなのですよね。別にコンテナ化やマイクロサービス化そのものが目的なのではなく。だからECSとかオススメしやすい。
[slideshare id=8zzTSGWxPrc03i?startSlide=9&w=595&h=485&fb=0&mw=0&mh=0&style=border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;&sc=no]
先日のサンフランシスコのAWSサミットの@Wernerのキーノートでも↓のように、このことが言われていて、現場でも、とにかくお客様のpainとなっている事象を集めてサービス開発に〜というのが徹底されていて、そういう所がブレない限りは、このAWSっていうプラットフォームへの自分のポジティブな感情が変わることは無いだろうなと思ったりする今日この頃です。
[slideshare id=1eGIniI6w6xHeE?startSlide=15&w=595&h=485&fb=0&mw=0&mh=0&style=border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;&sc=no]
オライリージャパン (2016-08-17)
売り上げランキング: 132,597
オライリージャパン
売り上げランキング: 19,854
コメント