こんにちは。LINEの鈴木です。 AWS SUMMIT TOKYO 2016が6月1日から3日にかけて開催されました。私は開発環境改善とサービス開発支援に従事していますが、近年のDevOpsにおいて Amazon Web Services (AWS)のサービスや関連事例は見逃すことができません。今回はこのイベントに参加してまいりましたので、弊社におけるDevOpsの実践と比較しながらセッションを振り返ってみたいと思います。 AWS SUMMITとは その名の通りAWSに関するや事例や活用方法がAWSサービス提供側からだけではなくAWSを利用している企業からも様々な視点から紹介されるカンファレンスです。 私は LINE に入社する前に何度か参加したことがありますが、入社してしばらく経ちますので実に数年ぶりの参加です。General ConferenceとDeveloper Conferenceの2つが並行して行われていましたが、私は主にDeveloper Conferenceのセッションに参加しました。 弊社におけるDevOps 今回いくつものセッションで”DevOps”という単語を見聞きしました。その中には、オーディエンスが誤った解釈をしていると「◯◯を使うことが”DevOps”である」という主張をしているようにしか聞こえないのではないかというセッションもいくつかあったように感じました。 クラウド環境でコンテナを BlueGreen Deployment によって配布したり、モダンなプロビジョニングフレームワークを用いたり、CI を活用していくことが”DevOps”なのでしょうか？ Effective DevOpsでは一貫して”DevOpsは文化である”と説明しています。5000万デプロイ/年の実現や特定のツールや手法に頼ることそのものなどは結果的にそうなったというだけであって、それらを以って”DevOps”ではありませんよね。私たちの実践するDevOpsにおいては、「現在どういう問題があり、それを解決するためにはどのようにしたらよいのか」という視点が常に最初にあります。 あえて特筆するようなことではないように思えるかもしれませんが、「銀の弾丸」を求めてツールを選定することは非常にナンセンスですし、特定の何かによって誰しもの問題を等しく万能に解決することなどできるわけはありません。 ツールなどは現在の文化や方向に基づいて変化を推し進めるための加速器でしかなく、協調や親和の上で大きな力を発揮するものでしょう。私たちは常にそのように考えながら業務にあたっています。 開発文化 LINEの開発現場では、トライアンドエラーを容易に繰り返すことができる雰囲気があるように感じています。 トライアンドエラーのサイクルを多く繰り返せるということは多くの新しいアイデアを早期に試すことが出来るということになりますし、方向性を間違えていたとしてもすぐに新たな挑戦に向かって切り替えることがやりやすい土壌であるといえます。 失敗という経験がフィードバックを生みますし、フィードバックは次に生まれるアイデアの穴を埋める、あるいはより良くするために必要となります。 こういった文化についてはKeynoteやDevOpsに言及する多くのセッションの中で一貫して同じように説明されていました。 あるセッションの中で、日本企業では海外企業と比べて能力は遜色ないはずなのになぜ海外事例のようにうまくいかないのかという疑問に対して、失敗を許容する度合いの問題なのではないかという回答がありました。 前述したように私たちの実践するDevOpsにおいては協調と親和にまずは重きを置くという考え方があります。 失敗をするのも、失敗を許さんとするのもまた人です。 過度に失敗を恐れずに新しい挑戦をしやすいようにBlamelessnessな文化づくりに貢献することも私たちの重要なミッションのうちの1つです。 弊社サービスのプロダクション環境 LINE のサービスの多くは自社で管理されている巨大なオンプレミスの環境から提供されています。 それら潤沢な IT リソースが専任のプロフェッショナルチームによって管理されています。 データストアもまた専任のチームに多くを任せることが可能な体制ですし、セキュリティについても専門チームによって堅牢性が担保されています。 また、AWSほど多機能ではありませんが少しの操作でサーバインスタンスを作成出来るインターナルなクラウドサービスも有しています。 このサービスはコーポレートストラクチャと連動していますので、作成完了を以って自動で適切なログイン権限が設定されます。 このような運営体制が確立していますので、開発者はわずかな労力で開発環境からセキュアなプロダクション環境までを自分の管理下に簡単に揃えることが可能です。 パブリッククラウドサービスを利用することで得られる利点の1つとして挙げられる、「必要なものを迅速かつ簡単に準備することが出来るために開発者は本来するべきことだけに集中しやすい」という観点においては遜色がないのではないでしょうか。 一方で、必要なときに必要なだけのリソースを確保し、必要な時期が過ぎたら廃棄するという所謂ディスポーザブルなインフラストラクチャを実現するという点では、パブリッククラウドサービスのスピードには及ばないためになかなか実現が難しい体制であると言えますが、これはそもそもクラウドとオンプレミスの特性の差に過ぎないでしょう。 しかしながら私たちは盲目的にパブリッククラウドサービスを利用することを否定しているのではなく、今後条件が合えば利用していく可能性も十分にあります。 弊社プロダクションサービスのデプロイメント 現在弊社では多くのプロジェクトが、PMC という名前の内製のフルスタックなデプロイメントシステムを用いて各々管理されています。(PMC については、昨年の LINE DEVELOPER DAY 2015 の一部セッションの中でも少しだけ触れられています。) PMCはデプロイメントシステムですから、当然ながらデプロイをより効率化するための機能を持っていますし、その他にもインベントリ情報の管理や権限管理、プロビジョニング、ログ管理など様々な機能を有するフルスタックなアプリケーションです。 そして、日々変化していく開発者の要求に応えるべく私たちはPMCのアップデートを継続して行っています。 私たちのサービスは日本の開発拠点だけではなく、諸外国の開発メンバーと協力して開発が行われています。 またいずれかの拠点でローンチまでを担当し、機能追加などは別の拠点に移管されるということも日常的に行われています。 デプロイメントをはじめとするプロジェクトマネジメントの方法が統一的でないと、それらの引き継ぎのために多くの時間を費やさなければならなくなってしまいます。 PMCはそういった問題も解決するために、内製でフルスタックで構成されています。 しかし一方で、歴史的な積み重ねによって PMCは巨大なモノリシックアプリケーションに成長してしまっており、機能追加や改修にかかるコストが無視できなくなっています。 そこで現在では私たちは新しい機能を提供する場合や既存機能の改修を行う場合で、その機能が独立性の高いものである場合は単独のアプリケーションとして開発を行い、PMCとの連携は API 経由で行うようにするというようなアプローチを取っています。 事例セッションの中でCodePipelineが紹介されていましたが、デプロイを如何にわかりやすく効率化するかという観点において、PMCをアップデートしていく上で非常に参考にすべき点が多いと感じました。 CodePipelineはCodeDeploy, CloudFormation, ElasticBeanstalkなどと上手に組み合わせて利用することで絶大なパワーを発揮するサービスでしょうから、AWSでサービスを提供している場合にはとても魅力的なものでしょう。 PMCには効率化された配信、ビルドやCIとの連携の仕組みが既にあります。 それらを前述したようなMicroservices化するにあたり、効率的に連携させることを考える場合に大いに参考に出来ると感じました。 総括 これまで述べてきたように、私たちのミッションは開発者が本来すべき本質的なことに集中することが出来るような文化を伝導し、環境を維持していくことです。 したがって、何が何でも全てをツールを内製して解決するという考えでなく、今後の開発現場の需要によっては AWSを利用するということを選択することもあるでしょう。 いずれの場合においても、クラウドネイティブな環境下で培われたノウハウを体験しておくということは、選択の幅を広げることに繋がりますから非常に大きな資産となることでしょう。 謝辞 今回私たちは自分たちのなすべきことの本質は何かということと、今まさに行っていることが正しいアプローチであるのかどうかということを客観的に見直し、再考することが出来ました。 素晴らしい機会を提供していただき大変感謝いたしております。 また、本エントリを最後までお読みいただきありがとうございました。 エンジニア募集中! お決まりの締めで甚だ心苦しくはありますが、私たちはLINEの開発現場をより豊かにしていくための仲間を募集しております。 皆様のご応募をお待ち申し上げております。 DevOpsエンジニア【全事業対象】 DevOpsエンジニア（インフラプラットフォーム）【全事業対象】
↧