日本のインフラを支える「NTT」のJava技術サポートを一手に担うJVMエンジニア、久保田祐史氏。インフラに匹敵する大規模コミュニケーションアプリ「LINE」のHBaseエンジニア、鶴原翔夢氏。大規模JVMを支えるスペシャリストお二人に、開発・運用の裏話をたっぷりと伺ってきました！
目次
大規模なJVM運用の共通点
――お互い間接的にご存知だったそうですが、初対面ということでまずは自己紹介からお願いします。
鶴原（LINE）：私はLINEアプリのメッセンジャー機能のバックエンドの、アプリケーションサーバの開発をしています。LINEのサーバーサイドはJavaで書かれていて、多くの部分でHBase（※）を使用しています。私はHBaseの運用や、HBase周りのアプリケーション開発担当です。
※HBase…Apache HBase。JVM上で動作するNoSQLデータベース。
▲LINE株式会社 開発1室 鶴原 翔夢氏
久保田（NTT）：私はNTTグループ会社向けにOSS製品の技術サポートをする「OSSセンタ」という組織で、OpenJDK、JVM、Java中心にサポートする部隊のサポートリーダーを務めています。運用自体はしていませんが、困りごとを解決したり、現地に行って解析したり、パフォーマンスチューニングをしたりと。
トラブルシューティングのための情報収集を行う「HeapStats」というOSSのJVM解析支援ツールの開発にも携わっています。
▲日本電信電話株式会社 OSSセンタ 久保田 祐史氏
鶴原：全国のNTTグループ全てのサポートをされているんですか？
久保田：対象は全てではあるのですが、グループ会社の中でも主にSIerを中心にサポートを提供していますので、想像されているよりは少ないですね。なので、サポート対象はそれほど多くないです。
サポートも一度手を入れると現地できちんとノウハウ化されるので、問い合わせ自体減ってきました。5年前のサポートはすごく忙しかったけど、最近は割と余裕があるなあという感じがあります。
鶴原：トラブルを解決しつくしたってことですか、すごいですね（笑）。問い合わせ内容はどういうものが多かったんですか？
久保田：社内でのサポートに加えて社外でもJavaの困りごとを伺う機会が多いんですが、やはりGC（Garbage Collection）周りの相談がほとんどです。GCは初歩的な部分がわからないと、何をしたらいいか全然わからないところなんですよね。
鶴原：HBaseでもGC周りのトラブルは多いです。HBaseはデータベースなので、そこでStop The Worldが起きてしまうとアプリケーションの性能に大きく影響を与えてしまうんですよね。最近はHBaseのアップグレードやG1 GCへの切り替えでトラブルは減ってきましたが、障害が起きてしまったこともありました。
その時々で適した技術をチョイスする
久保田：そもそもなぜデータベースにHBaseを選択されたんですか？
鶴原：LINEアプリの立ち上げ当初はMySQLとRedisなどで作られていたんですが、ある日香港から大量のユーザ登録があって、そのときにMySQLの書き込みがボトルネックになりました。これをスケールさせないといけないということで、当時MongoDBやCassandra、HBaseなどでベンチマークをとったり使用感を試したりして、HBaseが我々の規模のスケールに対して有効そうだということで採用されました。
とはいっても時代によっていろいろな技術の変遷があるので、絶対にHBase、というわけではないです。いま一部ではCassandraを入れて試していたり、その時々で適したものをチョイスしています。
久保田：いまデータベース選定をやり直すなら何にしたいと思います？
鶴原：うーん。クラウドではGCPのSpannerやAWSのAmazon Auroraなど、SQLベースで世界規模でスケールするものにいきたいなという気持ちはあるんですが、現在のオンプレの運用とは異なる部分が多いのでなかなか踏み切れないですね。
他のプロジェクトではCassandraやMongoDBを使っているところもあるんですけど、それぞれJavaやC++側でトラブルも起こるので、今のところ乗り換えるほどの魅力は感じていないです。
久保田：確かに、私もCよりはJVMの方でトラブルが起きた方がなんとかできそうな気がします。
JVM運用を支えるさまざまな施策と連携
久保田：JVMにはもともと不得意な処理ってあるじゃないですか。例えば画像処理で、大きいオブジェクトを作って一気にやろうとしてGCが走りそうになるとか。サーバ自体をリッチにするのが難しい場合、いろいろな対策をとりますよね。
画像処理の部分だけCに置き換えて実装したり、バッチ的に処理したり、処理ごとにサーバーを分けたり。あるいはGCをコントロールしてメンテナンス期間などを設けて定期的に再起動するような「運用でカバー」といった対策も取れる。
一般的な社内向けシステムだと、業務アプリケーションの特性上アクセスが一気に増えるとか変わるとかいうことはあまりないので、メンテナンス期間を設けて1ヶ月に1回落とすような方法も取ったりしていました。いろいろな方法がありますが、LINEさんはどういうやり方なんですか？
鶴原：メインのアプリケーションサーバはTomcatで動いていて、デプロイのためにほぼ毎日再起動はしています。過去にGCが問題になったときはタイミングを見計らってリスタートといったことも、したような記憶があります。HBaseの場合はデータストアなので難しいところはあるんですけど……。
久保田：データベースの仕組みのなかには落とせない部分がありますもんね。
鶴原：Elasticsearchとかもそうだと思うんですけど、データベースをJavaで書くっていうとやっぱりGC問題が最後に立ちはだかるんですよね。
久保田：HBaseのトラブルはどんなものがありました？
鶴原：CMS GCの頃なんですけど、HBaseが内部的にすごく大きいオブジェクトを繰り返しつくってしまって、Full GCが走って止まってしまうってことがありました。
そのときはHBaseのパラメータを調整して解決しましたが、アプリケーション側でHBaseが得意ではない形のデータを作ってしまっているなど、そもそもの原因がアプリケーション側にあるということも多かったですね。
久保田：運用を重ねていくと、どういうオブジェクトが苦手だとか傾向がだんだんわかってきますよね。アプリケーション側の開発者とのノウハウの共有はどうやっていますか？
鶴原：私たちはHBaseを運用するチームがHBaseを使うアプリケーション側の開発も担当しているので、実は同じ人が書いているんです。なのでお互いコードレビューベースで「この形は危なそう」と共有する形ですね。
久保田：それはいいですね。
社内を横断する技術共有の仕組み
久保田：メトリクス（※）の監視なんかはどういう方法でやっていますか？
※メトリクス…データを収集して管理に使えるよう計算や分析を加えた評価指標
鶴原：アプリケーションサーバ内で発生するいろいろなメトリクスは、内製のモニタリングツールを使って監視しています。例えば「毎秒このくらいメッセージが送られている」とか「このAPIが何回コールされている」とかは、ライブラリを組み込んでAPIを呼んでおけば勝手にカウントしてサーバで呼んでグラフで見れる、という風になっています。
HBaseプロセスそのものの監視もいろいろやっていて、プロセスメモリの使用量、書き込みリクエストの秒間量などの監視にPrometheusを使っています。HBase自体がJMX（Java Management Extensions）でメトリクスをエクスポートしているので、PrometheusでJMXを読みにいって集めて、Grafanaで表示するようになっています。
久保田：Prometheusといえば、LINEエンジニアの湯川さんがブログで紹介したりPrometheus Casual Talksというイベントを開催したりしていますよね。
鶴原：そうなんです。実は湯川さんにPrometheusを紹介したのは僕なんですよ（笑）社内Wikiに書いたら湯川さんが興味を持って、あっという間に広めていてすごいなーと。
久保田：インフラのプロセス監視は全てPrometheusで統一しているんですか？
鶴原：全然、全社的な統一ではないです。LINEゲームアプリのバックエンドチームや統計解析専用のチームなど、他のHBaseを使っているチームでもそれぞれ違うモニタリングシステムを持っている状態です。
久保田：HBaseを担当しているチームがいくつかあるんですね。サービス、製品ごとにチームが分かれていて、それぞれにたまたまHBaseを選択したということですか？
鶴原：そうですね。ただ現状だと共有できていなくて無駄な部分もあるので、横断的に使えるように社内クラウドのようなものを整備しています。まだ完成していないんですが、いつかみんな共通の使い方でHBase対応にしたいなーという夢を抱いてます。
チャレンジを続けるための課題
久保田：社内でHBaseを広めていく過程で、現状課題だと思っているのはどんなことですか？
鶴原：大きくいうと2つあって、1つはやはり人手が足りないという問題と、もう1つはHBaseのバージョン問題ですね。2017年のLINE DEVELOPER DAYでも発表したんですけど、まだHBaseの古いバージョンを使っている部分があって、これまでのノウハウはそちらに偏ってしまっているんですよ。
過去1年くらいを通してHBaseのアップグレードをやってきて、ようやくこれから社内に広められるかなというところです。ただHBaseはやはりMySQLほど広く使われている技術ではないので、未踏のバグもまだ結構あるんですよね。
久保田：我々も過去にはJVMのバグを結構踏みましたね。バグを修正してOSSに貢献してという。
鶴原：そうですね、基本的に見つけたバグは貢献しています。ただ私のチームは5、6人で2000台くらいのサーバを見ているので、トラブルが起きるとそれを調べるだけでかなり時間を使ってしまうんですよね。クリティカルなバグが生じることもあるので、アップグレードもバックグラウンドでロードだけかけるようなことを半年間やったりして……慎重に進めてます。
久保田：うーん、それは人が足りないなあ（笑）我々の部隊も特殊な分野なので、なかなか難しいです。JVMではあるんですけど、コアまで見ているので実はJavaはほとんど書かなくて、メインはCやC++です。そもそもやりたいという人を見つけるのが難しい分野ですね。
最近はGoogleが提唱した「SRE（Site Reliability Engineering）」という表現がすごくいいなと思っていて、内容についてもそうですがなにより一見地味だけどすごいことやってるぞ、というのがもっと伝わればいいなと思っています。
鶴原：SRE、かっこいいですよね。久保田さんは社外での発表を積極的にされていますが、やはり魅力を伝えたいというモチベーションが大きかったんでしょうか。
久保田：最初に始めたときは、知識を全社的に底上げしたいという目的でした。サンフランシスコのJavaOne 2014での発表も、HeapStatsを開発したタイミングで「せっかくだからCFP（Call For Paper）出してみよう」と出したら思いがけず通って、結構バタバタしていました。継続的にやると名前を覚えてもらって結果的に、ということはあるかもしれません。
鶴原：私たちの仕事も基本オンプレなのでホットなクラウドの話題とは少し離れてしまうところがあるんですが、ならではの面白さをもっとアピールしたいと思ってます。
久保田：オンプレならサービスに合わせてマシンをカリカリにチューニングしていくのがかなり面白そうだなと思っています。
JVMの中に手を入れて、サービスをより効率良くぶん回して、性能良くして、1つ1つのプロセスの負荷をすごく低くしてという感じで……。私もサービス運用したいなって少し思います（笑）。
鶴原：実際にちょっとした最適化でマシンが半分で済んだり、全然ある話ですよね。チャレンジできる戦場があるのは嬉しいことです。
進化を続けるJavaへの期待
鶴原：我々は一昨年くらいにJava6からJava8へ移行したんですけど、すごくいいなと思っています。私はもともとPerlのようなLL言語でサクサク作るようなタイプだったので最初にJavaを触った時は結構モッサリしているイメージを持っていたんですけど、Java8ではLambdaがエラスティックにいろんな問題を解決しつつ、Lombokとか使って堅いJavaからは脱却したのかなと。
Java10のProposalを見ても、最近のKotlinやScalaのいいところがまたJavaにも入ってきて、Javaそのものが堅牢で実用的な言語になっていくんだろうというイメージを持っています。
久保田：言語としての使いやすさはかなり良くなっていますよね。私自身はいろんな機能や便利な部分をどんどん取り込んでリリースサイクルが早くなることは歓迎です。
ただJavaを使う多くの人が求めているだろうことは「非互換性が極力ないこと」で、「変わらないこと」がいいところでもあったんですよね。NTT含め多くのSIerでは、開発より運用の期間がずっと長くなる。非互換性がないことでソースコードがそのまま使えると。
Java8や9の非互換性を調査しているんですけど、細かいところは結構変わっています。良くも悪くも、運用のコストが高くなるのは確かだと思います。基本はLTS（Long Term Support）なので、開発者としてはJavaの進化は素晴らしいと感じていますけどね。
鶴原：最近Javaそのものが良くなってきていて、Java回帰のような流れがあるのかなと思っています。コミュニティやユーザの成熟度も群を抜いて高いので、Javaが良くなってくれることは嬉しいですね。
久保田：言語としての進化が早くなりましたよね。最近はGCの種類が増えてきたので調査をしているんですけど、JVMは新しいGCが導入されるのが早い印象ですね。今後3つほど新しいGCが入ってくる予定ですし、その一つのZGCはOracleラボで研究されたいろいろな調整が取り込まれそうだなと。
HBaseも、新しいGCになったらどうなるか調査をして、GC戦略をいろいろと考えてと、面白くなりそうですね。
鶴原：そうですね。私も期待しています。
【対談者プロフィール】
▲LINE株式会社 LINE開発1室 鶴原 翔夢（つるはら・とむ）氏
2013年にLINEに入社後、メッセージングサービスのサーバーサイド開発者として、主にHBaseと関連するプロジェクトに多く携わる。
▲日本電信電話株式会社 OSSセンタ 久保田 祐史（くぼた・ゆうじ）氏
Javaの調査検証やコア解析からシステムパフォーマンスチューニングまでこなすテクニカルサポートエンジニア。OpenJDKへの貢献（OpenJDK Author, icedtea Committer）やDuke’s Choice Award 2016を獲得したJavaトラブル支援ツールHeapStats の開発にも携わっている。
取材・執筆：dotstudio, inc. ちゃんとく
大学までは文系で法学を学んでいたが「モノを作れる人」に憧れて知識ゼロからWebエンジニアの道へ。転職し現在はIoT中心のエンジニア・テクニカルライターとして活動。Node.jsユーザグループ内の女性コミュニティ「Node Girls」を主催。Twitter: @tokutoku393 / dotstudio, inc.
※本記事は「CodeIQ MAGAZINE」掲載の記事を転載しております。
8,568通り、あなたはどのタイプ？
グッドポイント診断で、あなたの隠れた強みを診断してみましょう。
診断結果は8,568通り。あなたはどのタイプ？
あなたの新しい可能性が見つかるかも
リクナビNEXTにログインすると、あなたの志向に合った特別な求人一覧を見ることができます。
予想外の求人が、あなたの世界を広げるかもしれません。
