セッションのアジェンダと自己紹介
昔農凜太朗氏：本日は「Kubernetesでコンテナを使ってサービス化したら運用者がログを追えなくて工夫した話」というタイトルで、NTTコミュニケーションズイノベーションセンターの昔農が発表します。よろしくお願いします。
本日のアジェンダです。最初に発表したいことと伝えたいこと、その後、取り組みの最中にCloud Native化やコンテナ化を推し進める中で出てきたジレンマや、その問題に対するアプローチについて話します。途中、我々がどのようなかたちでソフトウェアを使ったアプローチをしたかというデモを簡単に紹介して、最後のまとめに進もうと思っています。
まず、簡単に自己紹介をします。昔農凜太朗です。NTTコミュニケーションズで、Site Reliability Engineerというジョブタイトルの仕事をしています。これまでのキャリアは、（スライドを指して）このようなものです。現在は、DevOps基盤のプロジェクトでSREとして従事しています。
Flexible InterConnectやDistributed Secure Internet GateWayなどのプロダクトの開発に携わってきました。「その他の主要公演」に記載したような外部発表も行っているので、もしCloud Nativeな技術に興味のある方がいれば、併せて見てもらえるとうれしいです。
本日の発表でお伝えしたいことです。今回は「Cloud Native化の仕事は組織との戦い」という話です。私たちのチームや組織は、弊社の「プロダクトライフサイクルを向上させよう」という取り組みを行っています。今日まで10を超えるプロダクトのCloud Native化を支援してきました。開発のライフサイクルの考え方、あるいは基盤自体のCloud Native化。そして、それを開発・運用する人材の育成に取り組んでいます。
会社や組織としても大きな大義名分をもって推し進めているという背景があり、私たちのチームや部署は、Center of Excellenceという役割を担っています。主に技術を軸に、いろいろな部署や部門がある会社を、横にブチ抜くことができるような役割を全社の合意のもとに進め、多くの組織や部門にまたがって組織的に技術やノウハウの展開ができています。
そのような大きな大義名分や背景がある中、実際、裏には多くのジレンマがありました。今日は、その中の問題の1つを取り上げて、私たちがどのようなソフトウェアのアプローチで解いていったかを話したいと思っています。
コンテナ化で出てきたログの課題とジレンマ
今回は、Cloud Native化をより具体的に、コンテナ化を推し進めるという文脈で話を進めていきます。実際、Cloud Nativeという言葉は非常に強いワードです。弊社でも、いわゆる“正義”という意味で扱っていたので、流れとして「次の開発からはCloud Native化を実施します」と言っても、真っ向から反対するような動きはそれほどありませんでした。
それを推し進める私たちの立場からすると、「絶対良いものになる」や「サポートもします」といった大義名分をもって仕事を進られたわけです。しかし、それを受け入れる立場としては、やはり新しいことを始めるのには常に不安がつきまとったり、今までやってきたこととの違いに戸惑ったりすることが、実際にあったのではと思っています。本日は、その取り組みの中でログに関連して顕著に出てきた課題を1つ話したいと思っています。
実際に、今まで開発した環境をいきなりCloud Nativeに持っていくと、どういうことが起きたか。（スライドを指して）「そんなある日、メンバーの困りごとに気づいた」という内容ですが、Kubernetesのコンテナにしてアプリケーションを動かした時に、「ログってどうやって見たらいいんですか」と、すごくピュアな質問をされました。
今までの、普通にLinux上でプロセスとして動いているログを見る時は、ファイルのかたちで扱えるので、例えばtail -fとするなど、いろいろな方法を使ってリアルタイムでログを見れていました。
端的にいうと、Kubernetesを使っている場合は、既存のログとは違う見方をしないといけません。よりCloud Nativeなアプローチをした時、例えばGKE、GCP上でKubernetesを動かしてる場合はCloud Monitoring、あるいはOSSを使う場合はGrafana Lokiなど、ログを可視化するようなツールを使うことによって見れます。
いきなり「明日からCloud Nativeだからこういう方式にしてください」と言えば、Cloud Native自体はいいものであると理解していても、実際には不便に感じる人がいました。Cloud Nativeという取り組みがいいことなのはみんなわかっていますが、それを推し進めたいと思っている自分がいる反面、一緒に働く隣のチームのメンバーを楽にできない事案があると、そんなCloud Nativeでいいのかとジレンマを感じる自分がいました。そのジレンマが本日の発表の趣旨になっています。
自分なりにこの問題を噛み砕いてみました。書き下ろすと、そんなに難しいことではなくて、「そりゃそうだよな」という話になりますが。
従来の方式では、systemdやSupervisordなどを使ってプロセス管理していたものが、KubernetesのPodになった。それに伴い、ログの扱いに関しても従来ファイルシステムにずっと残っていたものがKubernetesによってハンドリングされていくので、一部はローカルに残りますが、基本的には常にクラウド側に保存されています。それに伴い、ログへのアクセスも変わっていきます。
一番の違いは、これまでファイルの形式で扱えたログがCloud Native、本日の文脈ではKubernetesのPodになったことで、簡単にはそのように扱えなくなったことです。それがユーザーにとって大きな違いだと感じていました。これによって実際に何が困るかというと、例えばこれまで簡単にできていた（スライドを指して）ここにあるtail/cat/less/grep/uniq/wcなど、いろいろなコマンドが簡単には使えなくなります。
開発者の中には、デバッグなどの切り分けをする時に、自分がこれまで作ってきたワンライナーのほか、いろいろなものがありました。実態としてCloud Nativeになった途端、それらが使えなくなり、それがイマイチだなあと感じていました。結果として、自分でデバッグをした時に、確かにログの扱いに関しては少し不便になっていると感じました。
Cloud Nativeと共存するためのアプローチ
そこで、何を解決しなくてはいけないかをスライドにまとめています。問題を解決したいけれど、Cloud Native化を推し進めるのは絶対の前提条件です。必要に応じて、ログの扱いをオンプレの時代と同じようにする。すなわち、ファイルレベルでログが取り扱えるような状態を作りたい。
前提条件として、最後はCloud Nativeのアプローチに収束させたいと思っているので、Cloud Native化を妨げるような方法は採用しません。共存して橋渡しをするような解決方法が望ましいと考えていました。
（スライドを指して）最終的にどのような構成になったかについて、Google Cloud Platformを使った例を紹介します。Kubernetes上でアプリケーションを動かす前提では、GCPにはCloud Loggingというサービスがあり、基本的に常にKubernetes上で動いているPodのログをアグリゲートして、Loggingに保存してくれます。
それを、いわゆるData Ware Houseにログをどんどんシンクして永続化するようなアプローチを採用しています。これは、Cloud Nativeの中では極めて自然なアプローチだと思っていますが、Cloud Native化を目指したうえで設計されたインフラを利用して、今回の問題を解けないかというアプローチです。
（スライドを指して）この絵のとおり、Data Ware Houseに保存しているログをファイルの形式に書き戻してあげるようなアプローチを採用しています。これによって、BigQueryに保存してるログをオンデマンドにファイルのかたちで書き戻せます。
あるいはKubernetes上のアプリケーションを指定して取得できたり、任意の時間を指定できるようなかたちを採用することができます。もちろん、このBigQueryに保存されているデータは、他の用途にも利用できます。Cloud Nativeを実現しつつ、これまでできていたログのハンドリングも実現するようなかたちを採用しています。
ツールのデモ
それでは、簡単なデモを紹介するデモセッションに移ります。デモの流れは、先ほど説明したとおり、Kubernetes上で動いているPodのログがBigQueryに保存されている前提で、ログを実際にファイルというかたちで書き戻していきたいと思います。
書き戻しの対象にするPodは、Datadogのagentを使おうと思います。前提の条件として、kubectlでネームスペースを指定してPodsを取得すると、このようにDatadogのagentがいくつか動作しています。
このPodの中を複数のコンテナが動いている状態です。Datadogのagentの場合は、agentというコンテナとProcess Agentというコンテナが動作しています。
ふだんなら、kubectlを経由する場合は-cでコンテナを指定します。例えば今回の場合、tail -n 5などを指定してログの最後の部分だけ取得すると、このようなかたちのログが取得できます。
通常Kubernetesのログは、一定数が保存されると自動的にローテートされてしまうので、kubectlだけですべてのログを取得することはできないのがKubernetesの仕様です。今回は、すでにローテートされてしまったログをBigQueryのほうから取得するような動きになります。
今回の我々のツールは、BigQueryのクエリと掛けてはいますが、quemaruというものです。使い方はすごく簡単で、quemaruに対して先ほどのagentというコンテナの名前を与えると、デフォルトで直近1時間分のログを自動的にBigQueryから取得してくれます。
今実行したようなスピードで、直近1時間のログをフェッチしてきたところです。例えばheadでログを見てもらうと、0時45分からのログが取得されています。
46分のログが最初に出てきているのでtailすると、最後が1時41分です。この間のログがフェッチできるような仕組みです。
これによって、今Podが3つある状態でしたが、ログファイルもPodに合わせて瞬時に3つフェッチできるような動きになっています。
ツールの仕様で特筆すべき点
1つ特筆すべき点があります。今回デフォルトの挙動としては、現在時刻から直近1時間の動きをしました。もちろんBigQueryに保存されているログの期間、例えば1年から2年保存されているケースもあると思いますが、その期間であれば自由な時刻のログを抜き出してファイルのかたちで持ってこれます。
使用ケースとして、例えば「quemaru agent」と打って、-dで今月1日の状態がどうかというログを取得したい場合は、dayを指定するだけで今月1日の今と同じ時刻のログを自動的に取得できます。
併せて、今は直近1時間という指定でしたが、レンジを2などにすれば2時間分になります。
時刻の幅も自動的に変えることができるツールです。私たちはこのようにBigQueryにあるログをこのようなスピード感覚でファイルというかたちに書き戻せるツールを作り、Cloud Nativeとの橋渡しとして利用しています。
大切なのはシステムが人に合わせるようにソフトウェアを書くこと
最後に、まとめと今後の展望です。私たちはこれからもプロダクトライフサイクルの向上を目指します。大事なのは、人がシステムに合わせるのではなくシステムが人に合わせること。そういうソフトウェアを書いていきます。
今回のようなCloud Nativeの純粋なツールセットだけでは乗り切れない課題もあります。Cloud Nativeの常識やツールを押しつけるだけがCloud Nativeではありません。今後も、隣で一緒に働いている仲間を助けられるようなソフトウェアを書いていきます。
（スライドを指して）裁量のある働き方とありますが、Cloud Nativeのあるべき姿の中で、それを実際に業務に落とし込む時に何が必要かを常に考えて取り組んでいく。自ら考えて課題を定義し、それをソフトウェアで解いていくよう、これからも取り組んでいく必要があると思います。
我々はこのような活動をしていますが、一緒に働いてくれるメンバーを募集しています。もし興味があれば（応募してもらって）、一緒に働くメンバーが増えればいいなと思っています。ありがとうございました。
