この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、森です。
New Relic Advent Calendar 2019, 18日目のエントリーで
New Relic「クラウド移行で内製化しよう」セミナーに参加してきた ~ New Relicを使ったクラウド運用管理術 編 ~
の記事を書きました。
今回は同じセミナーであったセッションの1つである
- kubernetes環境にてアプリケーションの見える化を実現し運用を効率化する方法
のレポートになります
kubernetes環境にてアプリケーションの見える化を実現し運用を効率化する方法
株式会社マーケティングアプリケーションズ 社の 一海 隆太郎 氏のセッションです。
サーバーサイドエンジニアをやられている方で、直近では、メインプロダクトのデータセンターからGCPへの移行を担当されました。
今回はこのお話がメインとなります。
株式会社マーケティングアプリケーションズ 社のサービス紹介
マーケティングリサーチについて
企業のあらゆるマーケティング課題に対して、有効な意思決定をサポートするための科学的な調査・分析のこと
例えば、新商品の開発を行うとき
- どんなパッケージが生まれるのか
- 利用者の満足度は
- 競合商品との差は
- 若い世代が好きなものは
といったことを考える。
どういった手法を使うのかというと - グループインタビュー - ネットリサーチ - 電話調査 - 街頭調査 - 分析・解析
のようなことを行う。
マーケティングアプリケーションズ 社のサービスは主に ネットリサーチ で使われます。
ネットリサーチを行うとき
- メーカーがマーケティング課題を解決したい となると、調査を専門に行う会社に依頼をする
マーケティングアプリケーションズ 社は調査会社に対してネットリサーチを行うためのツールを提供している。 - アンケートシステム - 回答してくれる会員は約200万人
このアンケートシステムをオンプレデータセンターからGCPに移行した。
データセンターからGCPへの移行事例
どのように考えてGCPへの移行を進めたのか
背景としては
- データセンターの捕手が2020年で切れる
- 運用工数をできるだけ下げたい
というのがあった。
オンプレとクラウドのどっちにするかに関しては、
- オンプレ
- Pros
- 基盤選択から構築までの自由度が高
- Cons
- 買取または固定の維持費
- H/W調達などの運用コスト
- Pros
- クラウド
- Pros
- H/W調達などの運用コストがない
- マネージドサービスを利用することで管理する対象を減らせる
- Cons
- 構築の自由度はクラウドベンダーの提供依存
- Pros
最終的には運用を楽にするためにGCPに移行する決断をした。
場所を移したら終わり？
同じ構成のままリフトしても場所が変わっただけで運用が変わらず意味はないので、クラウドネイティブへシフトしよう。クラウドではクラウドのやり方ってものがある
- クラウドネイティブ
クラウドでの経験から「こういう構築・運用が良いよ」という概念を後付けで表したもの。
Cloud Native Computing Foundation (CNCF) が定義付けし、提唱している。
- クラウドネイティブの定義
- スケーラブルなアプリケーションを構築する能力を組織にもたらすもの
- コンテナオーケストレーションやイミュータブルインフラストラクチャ、宣言的APはあくまでそのアプローチの一つである
- 実現すべきは、回復力と管理力、可観測性を備えた疎結合なシステム
- 自動化により、堅牢かつ期待通りに、最小限の労力でシステム更新できる
何をシフトしたのか
アンケートシステムでは、
- 抽象化手法
- VM to Container
- 基盤
- VMware to Kubernetes
へそれぞれシフトした
移行においてどうNewRelicを活用したか
GCPに移行する際、様々な課題があるが、その中の一つとして - 移行後の環境が性能要件を満たすのか担保したい というのが大きい。
- APMを導入して性能試験をしたい
- 合わせてインフラ監視も行いたい
両方提供しているのは New Relic と Datadogで
上記の図のような比較で New Relicを導入することになった。
性能試験
- データセンター時代と同様の性能を出せること
- オートスケールが想定通り動くこと
Gatlingで負荷をかけつつ、NewRelicで性能やスケール状況を計測。
- 性能の計測
- 平均レスポンスタイム
- スループット(アクセス数)
- スケール状況の計測
- k８sのクラスター、Node、Podの状態の可視化により判断(New Relic上で異常というのがわかりやすい図が表示される)
結果、
- 安定時のレスポンスタイムは想定内
- オートスケールも想定通り
- スケールして安定するまでに時間がかかり、レスポンスタイムのピークが１.７秒ほどかかっていた
せめて1秒以内にしたかったので、環境の調整を行なった。
- Podのサイジング(CPU/メモリ)
- 初期Pod数
- Nodeのサイジング(CPU/メモリ)
計測を繰り返し、最終的に1秒以内まで短縮することに成功。
New Relicを導入することで性能検証ができ、安心していこうすることができた。
移行後に見える化で運用効率を向上させた
オンプレ時代の運用は、インフラ監視にZabbixを利用し、アプリケーション監視はなかった。
アプリケーションの状態がわからないので、
- アラートが鳴ったけど、何が起きてる？
- ユーザー影響は起きている？
- SLAの性能要件以上のアクセスがきてる？
これらのことを人力で調べていた。
- アンケートシステムを開いて利用状況を目視確認
- サーバのアクセスログを集計
- DBデータを検索
など。状況把握に時間がかかり対応が遅くなるのは明白。
GCP移行でNew Relicを導入したことにより、デフォルトで様々な情報が可視化できるようになった。
- 平均レスポンスタイム
- スループット
- エラー発生率
ただし、これだけではアンケートシステムの運用に活用できないケースが多い。
アンケートシステムの構成
- 様々な企業に導入してもらっている
- 契約プランが複数で、導入企業ごとの環境野生の上限が異なる
運用時に一番必要なのは、導入企業ごとの情報なので、導入企業ごとの可視化が行えれば良い。
New Relicでは、
- コードを数行書くことで任意のデータを連携できる
- 導入企業の識別子を連携することで識別子ごとに可視化できる
これらのことを行えば、あとはダッシュボードを作るだけ。
- アンケート配信状況
- アンケート回答状況
これらを可視化するダッシュボードを作ることにより、運用において重要な指標を可視化することができた。
アラートがなった時も、New Relicにより状況がすぐわかり早期対応ができるようになった。
まとめ
会社のメインとなるサービスのクラウド移行という難題を見事に成し遂げた話が聞けて非常に満足したセッションでした。
前半のセッションでも、移行後に運用ツールを導入するのではなく、移行計画の段階で導入するべき という話が出てきましたが、 まさにその通りでしたね。
現状の把握、移行に際しての問題の解決方法、移行後の運用の変化、New Relicをうまく活用することでより自分たちが力を入れるべきことに集中できるようになるので、よりサービスの質を高めてエンドユーザーに満足してもらえるようにしていく。これは最近のトレンドですね。
これからクラウド移行を行う計画をしている、クラウドネイティブなやり方に変えていきたいといった人にはとても参考になるのではないでしょうか。是非実践すべき内容だと思います。
ではでは。
40
