Container Replatform 101

既存アプリをコンテナ化したいのじゃが
- Kubernetesへリフトする開発者が乗り越える壁 -
Shingo Kitayama
Red Hat K.K.
Cloud Native Days Tokyo 2022

View Slide

Copyright © 2022 Red Hat K.K. All Rights Reserved.
Introduction
Shingo
Kitayama
Red Hat K.K.
Cloud Solution Architect, Technical Sales
OpenShift Architect
shkitayama
spchildren

View Slide

本日のゴール
アプリケーションプラットフォームの
Replatform化
01
まとめ
04
ログ設定
03
環境変数設定
02
注意) 本書は、以下のプロダクトに慣れ親しんでいることを前提としています
- Tomcat アプリケーションサーバーにデプロイされた、Linux仮想マシン上で実行される Java アプリケーション
- KubernetesのコンセプトとKubernetesの基本的なリソース

View Slide

アプリケーション
プラットフォームの
Replatform化

View Slide

コンテナ化にはマイクロサービスが必要？
Infra Resources
Hypervisor
仮想マシン
Guest OS
App App
「既存のアプリケーションコードに変更なく、Kubernetesの上にコンテナ化できますか !?」
仮想マシン
Guest OS
App App
Infra Resources
Kubernetes
コンテナ
Libraries
App App
コンテナ
Libraries
App App
定型的な回答
「 Kubernetes上で仮想マシンのようにプロセスを取り扱うと、開発の複雑さ、アプリ運用負荷(コスト)の増加、障害発生率の増加に
直結するため気をつけましょう。」
“Lift & Shift” is NOT recommended !?

View Slide

マイクロサービス化することのメリット
Development
Process
Operations
+ 分散システム
+ パフォーマンス
+ スケーラビリティ
+ 複数サービスの統合テスト
+ CI/CDの導入
+ デプロイメント方式
+ パッチ/リリースの方式
+ 横断的な監視
+ 障害の動的対応
+ セキュリティ対応
+ 分散システムの適用
+ パフォーマンス設計
+ スケーラビリティ設計
+ データ/トランザクション分離
+ ドメイン設計
+ 複数サービスの統合テスト
+ CI/CDの導入
+ デプロイメント方式
+ パッチ/リリースの方式
マイクロサービス化とは、全ての機能が1つのアプリケーションに統合されたモノリシックなサービスを、機能・用途に合わせて小さい
サービスに分割することで、アプリケーションの保守性や安全性を上げることです。
サービス機能を独立することで障害範囲を最小限にし、インフラリソースに障害が起きた場合でも、確実に回復および拡張できる状
態を目指します。
Architecture

View Slide

マイクロサービス化への投資判断
基盤システム移行
アプリ影響度調査
アーキテクチャ再設計コスト
アプリ改修実装コスト
既存運用変更コスト
ライセンスコスト
アプリの保守性向上
ノウハウ取得・学習コスト
実装したことがない不安
基盤システム移行
アプリ改修箇所の局所化
リソース利用率の最適化
動的スケールアウト
自律復旧による障害検知
ライブラリ管理の容易性
システム移行容易性(可搬性)
「まずはLift & Shiftしよう !!」
多くの場合マイクロサービス化のメリットを十分理解しても、システム移行時点でアプリケーション全部を改修する訳にはいきません。
事前に検討をした上で、見送る判断を行う企業も少なくありません。
リスクと労力の少ないアプローチを好む傾向
最終的な投資判断
予測不能 > 保守性と安全性

View Slide

Lift & Shiftとはどの移行戦略を示すのか
コンテナへのパッケージ化
マイクロサービス化
Kubernetesへの移行
参考: State of Application Modernization Report 2022
Refactor (マイクロサービス化)
既存アプリケーションのコアコードやアーキテクチャ
を保守体制に合わせて変更し、効果的なビジネス
ロジックを実装できるように再設計します
Replatform (Kubernetesへの移行)
既存アプリケーションのビジネスロジックやアーキ
テクチャを変更せずに、Kubernetesに最適化した
設定を利用します
Rehost (コンテナへのパッケージ化)
既存アプリケーションを最小限の変更でコンテナに
コピーし、これまで通りの設計で運用します
SaaS化
リスクと労力の少ないアプローチを好む傾向
塩漬け
撤退
*注背景理解のため参考資料をもとに、意図的に言葉をコンテナの文脈に
合わせています。また、これらはAWSの6 Strategies for Migrating
Applications to the Cloudの定義をベースとしています。
Lift & Shift

View Slide

Server
Server
Server
Tomcat
本資料におけるコンテナへの移行
Replatform
(Kubernetesへの移行)
Rehost
(コンテナへのパッケージ化)
既存のアプリ運用を変えずにクラウドやコ
ンテナへ持っていく手法
(スケールするたびに変更作業が必要)
Kubernetesに合わせたアプリ運用
へ移行する手法
(スケールしても変更作業が不要)
Lift & Shift Lift Tinker & Shift
設定ファイル
- server.xml
- context.xml
既存アプリケーション
Podman / Docker
Review.war
Container
設定ファイル
- server.xml
- context.xml
Server
Server
Review.war
Tomcat
Pod
設定ファイル
- server.xml
- context.xml
Review.war
Tomcat
Pod
本資料は
こちらが対象
Review.war

View Slide

Server
Application Serverをクラウドネイティブ化
02 - Refactor
(マイクロサービス化)
01 - Replatform
(仮想マシンの利用)
Server
Application Server
(Tomcat)
Server
JVM
Application
Server
Pod
JVM
Server
Server
Application
Server
JVM
Application
Framework
GraalVM
Application
Framework
GraalVM
Pod Pod Pod
Application Serverを
Kubernetesのワークロードに
アプリケーションアーキテクチャを
マイクロサービスに
(MicroProfileの活用など)
Review.war Review.war Review.war Review.war
Review.war

View Slide

段階的に運用をプラットフォームに合わせる
Kubernetesの恩恵
(アプリ運用の効率性)
アプリケーションの保守性
(アプリ変更の容易性)
Rehost
(コンテナへのパッケージ化)
01
Replatform
02
Refactor
(マイクロサービス化)
Refactor (マイクロサービス化)
開発者やビジネスオーナーを巻き込み、既存業務プロ
セスに即したビジネスロジックやアーキテクチャ変更を
行います
Replatform (Kubernetesへの移行)
ビジネスロジックのコード変更を伴わないため、アプリ
ケーションのアーキテクチャ変更はありませんが、運
用をKubernetesに依存させます
メリット
- Shorter test/release cycle
- Increased scalability & elasticity
- Data managed by event driven architecture
メリット
- Improve monitoring
- Simplifies platform management
0
既存アプリのRefactorを計画している人の90％は、最初に
それらをReplatformするところから実施しています。
Rehostだけ検討したアプリをKubernetesに
持っていくと障害 (失敗) に繋がりやすい
01
02

View Slide

The Twelve-Factor app
KubernetesへReplatformするということは、「The Twelve-Factor App」の原則に則った仕様に変更すること

View Slide

The Twelve-Factor app
モダンなWebアプリケーションとしてのあるべき姿を12個のベストプラクティスにまとめた方法論
本日のトピック

View Slide

環境変数設定

View Slide

JVMとKubernetesの期待
Pod Pod
Container
Application
Server
JVM
Container
Application
Server
JVM
Server
Application Server
(Tomcat)
JVM
可搬性のレイヤ
(Replatform)
1 JVM上に複数のアプリケーションが稼働
1 コンテナに 1 プロセス(.war)が稼働
プロセスの
運用機能
* コンテナイメージの再利用性を重視
Java プロセスの場合は、Application Serverが行っていた運用機能をどこまでKubernetesにオフロードできるかを検討しましょう
* Javaバイナリ(.jar,.war,.ear)の
再利用性を重視
Catalog.war
Review.war
Review.war Catalog.war
JVMワークロード
における期待
Kubernetesワークロード
における期待

View Slide

Application Server
(Tomcat)
Service
Engine
Container
Container
Tomcatの運用機能とは
Application Server
(Tomcat)
JVM
Pod
プロセスの運用機能
Pod
プロセスの管理/運用機能
Connector
Realm Logger
JNDI
Host
Context
Logger
Valve
Connector
Host
Context
Logger
Valve
設定ファイル
- server.xml
- context.xml
Web Servers
HTTP(S) AJP
- リソース接続設定
- デプロイ管理
- セッションレプリケーション
などの設定を切り離して
Kubernetesに適用します。

View Slide

Application Server
(Tomcat)
Service
Engine
Tomcat設定のおさらい
Host
Context
Host
Context
参考
server.xml (サーバ設定)
$CATALINA_HOME
conf
context.xml (デフォルト設定)

webapps
logs
Review (コンテキスト)
Catalog (コンテキスト)
WEB-INF
classes (プログラム)
web.xml (アプリ設定)
コンテキスト設定
グローバル設定

View Slide

データベース接続の環境変数化
server.xmlやcontext.xmlに定義された外部リソース接続
情報(JNDI: データベースやメールサーバ接続など)を環
境変数に置き換えます。
name="jdbc/postgres" auth="Container"
type="javax.sql.DataSource“
driverClassName="org.postgresql.Driver"
url="jdbc:postgresql://127.0.0.1:5432/mydb"
username="myuser"
password="mypasswd"
/>
type="javax.sql.DataSource"
url="${POSTGRES_URL}"
username="${POSTGRES_USERNAME}"
password="${POSTGRES_PASSWORD}"
/>
Pod
Container
Application
Server
JVM
Pod
Container
PostgreSQL
環境に依存しないように、
起動時に接続先を指定します
* 同一Podの中にSidecarとして異なる役割のプロセスを
置くと、スケールが難しくなるため分離してください。
server.xml or web.xml
改修前
改修後
環境変数化
Review.war

View Slide

環境変数はApplication Server中に!?
type="javax.sql.DataSource"
url="${postgresdb.url}"
username="${postgresdb.username}"
password="${postgresdb.password}"
/>
postgresdb.url=jdbc:postgresql://127.0.0.1:5432/mydb
postgresdb.username=myuser
postgresdb.password=mypasswd
application.properties
webapps
Review (コンテキスト)
WEB-INF
classes (プログラム)
web.xml (アプリ設定)
コンテキスト設定
application.properties
Review.war
Maven
Gradle etc
Application Serverで変数を管理すると、環境変更
のたびにコンテナビルドが必要
変数値設定
接続設定

View Slide

変数値設定をKubernetesへ委譲
Pod ConfigMap / Secret
Container
Application
Server
JVM
Review.war
(1) 設定ファイルをマウント (2) 環境変数を指定
変数は極小化できる方が運用の効率性は上がります。極力、KISS (Keep it short and simple.)の原則に従いま
しょう。
設定ファイル
+ ファイルだと中身がどう変わったのか分かりづらい
+ 変更が多い場合はファイル管理のほうが楽
+ 変更点が理解しやすい
+ 変更が多い場合は変数値管理が面倒
Container
Application
Server
JVM
Review.war
変数値
kind: Secret
apiVersion: v1
metadata:
name: postgres_connection
data:
postgres.url: jdbc:…
postgres.user: myuser
kind: Secret
apiVersion: v1
metadata:
name: properties
data:
application.properties: |
Better
あらかじめserver.xml / web.xmlをテンプレート化して
コンテナをビルドしておく

View Slide

コンテナの環境変数から変数値を取得
Container
Application
Server
JVM
Review.war
変数値
org.apache.tomcat.util.digester.PROPERTY_SOURCE=
org.apache.tomcat.util.digester.EnvironmentPropertySource
参考: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#features.external-config.files.property-placeholders
https://tomcat.apache.org/tomcat-10.1-doc/config/systemprops.html
apiVersion: v1
kind: Pod
metadata:
name: tomcat
spec:
containers:
- name: tomcat
image: docker.io/tomcat:10.1.1
ports:
- containerPort: 8080
env:
- name: POSTGRES_URL
valueFrom:
secretKeyRef:
key: postgres.url
- name: POSTGRES_USER
valueFrom:
secretMapKeyRef:
key: postgres.user
環境変数の有効化 - Tomcatの場合
propertiesをホストの環境変数から読み取れるように
CATALINA_OPS(or catalina.properties)を設定しておきます

View Slide

ログ設定

View Slide

Kubernetesのログの取り扱い
+ アプリケーションに障害が起きるとPodごと消える
(可能性がある）ため、障害が起きたコンテナに入り、
ログを見ることができない。
+ どのノードでコンテナが動いているか意識しないた
め、どこで障害が発生しているのかわからない。
既存のログ管理と異なる点 Pod
Container
Application
Server
Review.war
stdour/stderr
Pod
Container
Application
Server
Review.war
stdour/stderr
Logファイル
kubeletはコンテナをログとともに管理します。Podが
ノードから削除されると、対応する全てのコンテナが、
ログとともに削除されます。

View Slide

ログの取扱いに関する責任分担
Pod
Container
Application
Server
Review.war
stdour/stderr
Pod
Container
Application
Server
Review.war
stdour/stderr
Logファイル
fluentd
Logging
Platform
転送
参考: https://speakerdeck.com/yosshi_/kubernetes-loggingru-men
詳しく解説
ログの外部転送はSREに任せましょう…。
アプリケーション開発者
+ ログを標準出力(stdout/stderr)
+ ログに対してフラグが立てられるようにログフォーマット
を設定
本資料は
こちらが対象

View Slide

ログの取扱いに関する責任分担
Pod
Container
Application
Server
Review.war
stdour/stderr
Pod
Container
Application
Server
Review.war
stdour/stderr
Logファイル
fluentd
Logging
Platform
転送
参考: https://speakerdeck.com/yosshi_/kubernetes-loggingru-men
詳しく解説
ログの外部転送はSREに任せましょう…。
アプリケーション開発者
+ ログを標準出力(stdout/stderr)
+ ログに対してフラグが立てられるように設定本資料は
こちらが対象

View Slide

Tomcatのログ設定のおさらい
Tomcatのjava.util.logging API実装（JULI）
server.xml (サーバ設定)
conf
logging.properties
lib
logs
グローバル設定
参考
$CATALINA_HOME
catalina.YYYY-MM-DD.log
localhost_access_log.YYYY-MM-DD.log
handlers = 1catalina.org.apache.juli.FileHandler, ¥
2localhost.org.apache.juli.FileHandler, ¥
3manager.org.apache.juli.FileHandler, ¥
java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
…
ファイル出力ハンドラ標準出力ハンドラ
Logファイル標準出力
Access Log Valve
logging.properties

View Slide

Tomcatのアクセスログ
unpackWARs="true" autoDeploy="true">
prefix="localhost_access_log" suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />

Tomcatのアクセスログは、 org.apache.catalina.AccessLogインターフェイスを実装するValveによって実行されます。
server.xml
Pod
Container
Application
Server
Review.war
stdour/stderr
出力先のファイルを/dev/stdout へ!?!?

View Slide

標準出力 or ディスク管理
Pod
Container
Application
Server
Review.war
(1) 標準出力に設定 (2) ディスク管理
logback-accessを利用することで出力先を標準出力に
設定
+ アプリケーションプラットフォーム側に設定が必要
PVをログディスクとしてマウント
+ Logging Platform以外にディスる管理が別途必要
Pod
PV
Container
Application
Server
JVM
Review.war
ログディスク
./logs/
Better
stdour/stderr

View Slide

Tomcatのアクセスログ

combined

Logback.web

LOGBACKはTomcat のクラスを拡張します。
Valveは通常、一緒に関連付けられて処理パイプラインを形成します。
ch.qos.logback.access.tomcat.LogbackValve
を使用するためにserver.xmlに追加
server.xml
Pod
Container
Application
Server
Review.war
stdour/stderr

View Slide

まとめ

View Slide

Server
The Twelve Factorの原則にしたがってReplatformを
01 - Replatform
(仮想マシンの利用)
Server
Application Server
(Tomcat)
Server
JVM
Application
Server
Pod
JVM
Application
Server
JVM
Pod
Review.war Review.war
Review.war

View Slide

linkedin.com/company/red-hat
youtube.com/user/RedHatVideos
facebook.com/redhatinc
twitter.com/RedHat
Thank you
Red Hat is the world’s leading provider of enterprise open source
software solutions. Award-winning support, training, and consulting
services make Red Hat a trusted adviser to the Fortune 500.

View Slide

Container Replatform 101

Container Replatform 101

Shingo.Kitayama

More Decks by Shingo.Kitayama

Other Decks in Technology

Featured

Transcript