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
Workforce Identity を使った 権限管理で Cloud Run を動かしてみた
satohjohn
0
210
Gemini + Vertex AI を使って作業を自動化「していく」
satohjohn
0
54
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
ARA Ansible for the teams
kksat
0
150
AWS Organizations で実現する、 マルチ AWS アカウントのルートユーザー管理からの脱却
atpons
0
130
chibiccをCILに移植した結果 (NGK2025S版)
kekyo
PRO
0
210
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
110
Java Webフレームワークの現状 / java web framework at burikaigi
kishida
9
2.2k
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns
mokuo
41
15k
“あなた” の開発を支援する AI エージェント Bedrock Engineer / introducing-bedrock-engineer
gawa
11
1.8k
AHC041解説
terryu16
0
590
[JAWS-UG横浜 #79] re:Invent 2024 の DB アップデートは Multi-Region!
maroon1st
1
140
CNCF Project の作者が考えている OSS の運営
utam0k
5
690
2024年のWebフロントエンドのふりかえりと2025年
sakito
1
230
技術を根付かせる / How to make technology take root
kubode
1
240
Featured
See All Featured
The Language of Interfaces
destraynor
156
24k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
630
4 Signs Your Business is Dying
shpigford
182
22k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
29
2.2k
Navigating Team Friction
lara
183
15k
Docker and Python
trallard
44
3.3k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
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
おわり