Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コンテナ環境のKotlinアプリケーション を運用しよう _ Google Cloudを使って
Search
SatohJohn
April 07, 2023
Programming
0
160
コンテナ環境のKotlinアプリケーション を運用しよう _ Google Cloudを使って
2023/04/07 Server-Side Kotlin Meetup vol.8 『初オフラインLT大会!』での発表スライドです
SatohJohn
April 07, 2023
Tweet
Share
More Decks by SatohJohn
See All by SatohJohn
Open Feature 面白いぞ
satohjohn
0
8
Workforce Identity を使った 権限管理で Cloud Run を動かしてみた
satohjohn
0
240
Gemini + Vertex AI を使って作業を自動化「していく」
satohjohn
0
58
Cloud_Run_GPU___Gemma_2_を使った_LLM_アプリケーション開発のススメ.pdf
satohjohn
0
17
Firebase Authenticationのセッション管理術
satohjohn
2
2.2k
お客様とすすめる_フロントエンドの技術支援.pdf
satohjohn
1
1.1k
GCPでのバッチ処理パターンを考えてみる
satohjohn
1
1.2k
GCPと連携してマスターデータ更新
satohjohn
0
200
Nuxt.js + Google App Engine でのアプリケーション開発の勘所
satohjohn
0
460
Other Decks in Programming
See All in Programming
5分で理解する SOLID 原則 #phpcon_nagoya
shogogg
1
280
ファインディLT_ポケモン対戦の定量的分析
fufufukakaka
0
890
バッチを作らなきゃとなったときに考えること
irof
2
490
Serverless Rust: Your Low-Risk Entry Point to Rust in Production (and the benefits are huge)
lmammino
1
140
Django NinjaによるAPI開発の効率化とリプレースの実践
kashewnuts
1
200
GitHub Actions × RAGでコードレビューの検証の結果
sho_000
0
290
もう僕は OpenAPI を書きたくない
sgash708
5
1.9k
コードを読んで理解するko build
bells17
1
100
CloudNativePGを布教したい
nnaka2992
0
110
CI改善もDatadogとともに
taumu
0
180
1年目の私に伝えたい!テストコードを怖がらなくなるためのヒント/Tips for not being afraid of test code
push_gawa
1
490
昭和の職場からアジャイルの世界へ
kumagoro95
1
410
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
430
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
Writing Fast Ruby
sferik
628
61k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
Scaling GitHub
holman
459
140k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Agile that works and the tools we love
rasmusluckow
328
21k
The Language of Interfaces
destraynor
156
24k
A better future with KSS
kneath
238
17k
Transcript
コンテナ環境のKotlinアプリケーション を運用しよう ~ Google Cloudを使って ~ 2023/04/07 Server-Side Kotlin Meetup
vol.8 『初オフラインLT大会!』 株式会社スリーシェイク佐藤慧太@SatohJohn
自己紹介 • 佐藤慧太@SatohJohn • 今年1月 株式会社スリーシェイク入社 • SREとして、お客様の労苦<Toil>を なくす活動に従事 •
趣味は、嫁の観察、プログラミング • 最近はGoogle Cloudの資格勉強
株式会社スリーシェイクについて 3 Copyright © 3-shake, Inc. All Rights Reserved.
xOps Plattform DesignOps IaaS DevOps / SRE RevOps (Revenue Ops) HR(Engineer Hiring) HROps Data Engineering DataOps Security DevSecOps SecOps 事業者が抱える セキュリティリスクを無くす 本格的な脆弱性診断を 無料で手軽に セキュリファイ Security 良いエンジニアに良い案件を フリーランスエンジニアに 「今よりいい条件」を リランス HR(Engineer Hiring) あらゆるサービスを連携する ハブになる クラウド型ETL/データパイプ ラインサービスの決定版 レコナー Data Engineering 日本のSREをリード SRE総合支援からセキュリティ 対策を全方位支援 スリーク SRE スリーシェイク = xOps領域のプラットフォーマーへ
「どこで」「何を」「どうやって」 調べていくかの取っ掛かりになってほしい 本日のスライドの目的 Kotlin書きやすいし、良さそうで 選んだけど運用ってどうやればいいの? https://furandon-pig.github.io/fpig_sample/hobby/bad_spiral/
Kotlinの運用難しい?
コンテナ環境における Kotlinの運用で必要なことは?
アプリケーションの計測、可視化
Kotlinの運用で必要なこと • アプリケーションの計測と可視化が必要である ◦ アプリケーションログやメトリクス ◦ JVMのチューニングに必要なログ • 可視化、計測しないと、なんとなくの判断で 障害や課題に対応することになる
Kotlinの運用で必要なこと • アプリケーションの計測と可視化が必要である ◦ アプリケーションログやメトリクス ◦ JVMのチューニングに必要なログ • 可視化、計測しないと、なんとなくの判断で 障害や課題に対応することになる
他の言語で書いた アプリケーションでも必要なこと
なんでJVMがコンテナ環境で運用が難しい (と思われている)のかの個人的見解 • コンテナ環境の運用に慣れていない ◦ 見たものをそのまま取ってこれない ▪ コンテナ内のログの消失 ▪ コンテナ内のアプリケーションと
メトリクス取得のための exporterとの共存
なんでJVMがコンテナ環境で運用が難しい (と思われている)のかの個人的見解 • コンテナ化=Cloud RunなどのServerlessで使うんでしょ? ◦ そもそものJVMの起動スピードの問題 ◦ 一定期間で停止するのでチューニングがそもそも難しいし 取る必要がない可能性もある
• そもそもJVMのログ解析、難しい
コンテナ化=Cloud Run などのServerless?
コンテナ化しているそもそもの理由 • ステートレスな環境の作成して、各個人の実行環境の差異を減らす • ポータビリティを高めて、様々な場所で実行できるようにする • 環境を閉じ込めているので検証が楽 ◦ JDKのバージョンアップにも対応しやすいできる
コンテナ化しているそもそもの理由 • ステートレスな環境の作成して、各個人の実行環境の差異を減らす • ポータビリティを高めて、様々な場所で実行できるようにする • 環境を閉じ込めているので検証が楽 ◦ JDKのバージョンアップにも対応しやすいできる メリットは多いよね!
じゃあ Google Cloudで やってみよう
前提 • Spring Boot WebFlux + Kotlin • GCEでDockerを建てて起動 •
以下を利用する ◦ Cloud Logging ◦ Clout Monitoring ◦ Cloud Profiler
Cloud Logging • とりあえずログを流しておいて、フィルターして探る ◦ 基本的にアプリケーションログはここに流してしまう • 使えるユースケース ◦ 何時に、何件ぐらい出ているのかの確認
◦ 作成したfilterをチーム内で共有して障害や検証時に素早く対象箇所を見つける
Cloud Logging(設定) • docker run時に --log-driver=gcplogs をつけるだけ ◦ logにラベルをつけたい場合は --log-opt
logs=〇〇,△△ --label 〇〇=hoge --label △△=fuga https://docs.docker.com/config/containers/logging/gcplogs/ docker run \ --log-driver=gcplogs \ --log-opt labels=app,ver --label app=sskt --label ver=1 \ --name sskt imageName
Cloud Loggingの クエリ jsonPayload.instance.name ="sskt" jsonPayload.container.metadata.app ="sskt" logName="projects/projectId/logs/gcplogs-docker-driver" 右の例だと、 •
インスタンスの名前 • コンテナのlabel • ログの種類で絞れる サンプルのクエリもあるので 勉強できる log4jにおけるセキュリティ侵害 のチェック のパターンもある
Cloud Monitoring • CPUやメモリの状態、JVMなどheapのデータをダッシュボード形式で 確認できる • 閾値に対してアラートを設定できる • 使えるユースケース ◦
Prometheus形式でのログを受信する ◦ SLO/SLIに設定した閾値を超えた場合に、アラートを送信する
Cloud Monitoring(設定方法) 1. GCEに対してOpsエージェントを追加する 2. Spring Boot Actuator + Micrometer
prometheusを利用してログを出力する a. io.github.mweirauch:micrometer-jvm-extras を追加します i. レポジトリに https://central.sonatype.com/artifact/ を追加します @Bean fun processMemoryMetrics(): MeterBinder { return ProcessMemoryMetrics() } @Bean fun processThreadMetrics(): MeterBinder { return ProcessThreadMetrics() }
Cloud Monitoring(設定方法) 3. GCEの/etc/google-cloud-ops-agent/config.yaml に以下を追加する metrics: receivers: prometheus: type: prometheus
config: scrape_configs: - job_name: 'app' scrape_interval: 5s metrics_path: /actuator/prometheus static_configs: - targets: ['localhost:80'] service: pipelines: prometheus_pipeline: receivers: - prometheus
Cloud Monitoringでの見え方(JVMのHeapやリクエストRateなどが見れる) 複雑なものはそこまで作れない grafana のhttps://grafana.com/grafana/dashboards/4701-jvm-micrometer/ の指標を利用
監視している値に対して、 閾値を設定し、閾値を超えたら通知でき る • Slack • PagerDuty などなど https://cloud.google.com/monitoring/ support/notification-options?hl=ja#pa
gerduty アラートの設定
Cloud Profiler • APM(Application Performance Management)の一つ • 内部のアプリケーション内のメソッドの呼び出しのCPU時間などがわかる ◦ Javaの場合は、Heapなども出てくる
◦ 時間帯で区切って平均で出される • 使えるユースケース ◦ アプリケーションのパフォーマンスチューニング
Cloud Profiler(設定方法) 1. コンテナにProfilerエージェントをインストールする 2. Service Accountの.jsonを /root/.config/gcloud/ に配置する 3.
アプリケーション起動時にProfilerを一緒に起動する java \ -agentpath:/opt/cprof/profiler_java_agent.so=-cprof_service=sskt,-logtostderr \ -jar myApp.jar
Cloud Profiler(Gradle Jib Pluginを使っている場合のパターン jib { from { image =
"〇〇" //ここにprofilerエージェントを追加している想定 } to { image = "〇〇" } container { jvmFlags = ["-agentpath:/opt/cprof/profiler_java_agent.so=-cprof_service=sskt,-cprof_cpu_use_per_thread_timer s,-cprof_enable_heap_sampling,-logtostderr,-minloglevel=2"] creationTime = "USE_CURRENT_TIMESTAMP" } extraDirectories { paths { path { from = './auth' into = '/root/.config/gcloud/' includes = ['*.json'] } } } }
CPU時間だけでみるとこんな感じ
クリックして深堀りができる(そのメソッドの中で何が呼ばれているのか)
まとめ
まとめ • コンテナが一般化してきた中でServerSide Kotlinの Google Cloudを使った運用について以下で対応できる ◦ Cloud Logging ◦
Cloud Monitoring ◦ Cloud Profiler ◦ 他にもCloud TraceやError Reportingなど 運用の手助けができます!
Kotlinの運用 できそうじゃない?
「運用する」と心の中で思ったならッ! その時スデに行動は終わっているんだッ!
参考 • Cloud Logging ◦ https://cloud.google.com/logging/docs/overview?hl=ja • Cloud Monitoring ◦
https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/fleet-installation? hl=ja • Cloud Profiler ◦ https://cloud.google.com/profiler/docs/profiling-java?hl=ja
おわり