Container Replatform 101

CloudNative Days Tokyo 2022 (2022/11/21-22)
「【既存アプリをコンテナ化したいのじゃが】-Kubernetesへリフトする開発者が乗り越える壁-」
で発表した資料です。

以下でビデオ配信もしていますので是非御覧ください。
https://event.cloudnativedays.jp/cndt2022/talks/1565

Transcript

1. 既存アプリをコンテナ化したいのじゃが - Kubernetesへリフトする開発者が乗り越える壁 - Shingo Kitayama Red Hat K.K. Cloud Native Days Tokyo 2022
2. 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
3. Copyright © 2022 Red Hat K.K. All Rights Reserved. 本日のゴール アプリケーションプラットフォームの Replatform化 01 まとめ 04 アプリケーションプラットフォームの ログ設定 03 アプリケーションプラットフォームの 環境変数設定 02 注意) 本書は、以下のプロダクトに慣れ親しんでいることを前提としています - Tomcat アプリケーションサーバーにデプロイされた、Linux仮想マシン上で実行される Java アプリケーション - KubernetesのコンセプトとKubernetesの基本的なリソース
4. アプリケーション プラットフォームの Replatform化
5. Copyright © 2022 Red Hat K.K. All Rights Reserved. コンテナ化にはマイクロサービスが必要？ 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 !?
6. Copyright © 2022 Red Hat K.K. All Rights Reserved. マイクロサービス化することのメリット Development Process Operations + 分散システム + パフォーマンス + スケーラビリティ + 複数サービスの統合テスト + CI/CDの導入 + デプロイメント方式 + パッチ/リリースの方式 + 横断的な監視 + 障害の動的対応 + セキュリティ対応 + 分散システムの適用 + パフォーマンス設計 + スケーラビリティ設計 + データ/トランザクション分離 + ドメイン設計 + 複数サービスの統合テスト + CI/CDの導入 + デプロイメント方式 + パッチ/リリースの方式 マイクロサービス化とは、全ての機能が1つのアプリケーションに統合されたモノリシックなサービスを、機能・用途に合わせて小さい サービスに分割することで、アプリケーションの保守性や安全性を上げることです。 サービス機能を独立することで障害範囲を最小限にし、インフラリソースに障害が起きた場合でも、確実に回復および拡張できる状 態を目指します。 Architecture
7. Copyright © 2022 Red Hat K.K. All Rights Reserved. マイクロサービス化への投資判断 基盤システム移行 アプリ影響度調査 アーキテクチャ再設計コスト アプリ改修実装コスト 既存運用変更コスト ライセンスコスト アプリの保守性向上 ノウハウ取得・学習コスト 実装したことがない不安 基盤システム移行 アプリ改修箇所の局所化 リソース利用率の最適化 動的スケールアウト 自律復旧による障害検知 ライブラリ管理の容易性 システム移行容易性(可搬性) 「まずはLift & Shiftしよう !!」 多くの場合マイクロサービス化のメリットを十分理解しても、システム移行時点でアプリケーション全部を改修する訳にはいきません。 事前に検討をした上で、見送る判断を行う企業も少なくありません。 リスクと労力の少ないアプローチを好む傾向 最終的な投資判断 予測不能 > 保守性と安全性
8. Copyright © 2022 Red Hat K.K. All Rights Reserved. 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
9. Copyright © 2022 Red Hat K.K. All Rights Reserved. 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
10. Copyright © 2022 Red Hat K.K. All Rights Reserved. Server Application Serverをクラウドネイティブ化 02 - Refactor (マイクロサービス化) 01 - Replatform (Kubernetesへの移行) 既存アプリケーション (仮想マシンの利用) 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
11. Copyright © 2022 Red Hat K.K. All Rights Reserved. 段階的に運用をプラットフォームに合わせる Kubernetesの恩恵 (アプリ運用の効率性) アプリケーションの保守性 (アプリ変更の容易性) Rehost (コンテナへのパッケージ化) 01 Replatform (Kubernetesへの移行) 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
12. Copyright © 2022 Red Hat K.K. All Rights Reserved. The Twelve-Factor app KubernetesへReplatformするということは、「The Twelve-Factor App」の原則に則った仕様に変更すること
13. Copyright © 2022 Red Hat K.K. All Rights Reserved. The Twelve-Factor app モダンなWebアプリケーションとしてのあるべき姿を12個のベストプラクティスにまとめた方法論 本日のトピック
14. アプリケーション プラットフォームの 環境変数設定
15. Copyright © 2022 Red Hat K.K. All Rights Reserved. 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ワークロード における期待
16. Copyright © 2022 Red Hat K.K. All Rights Reserved. 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に適用します。 Review.war Catalog.war Review.war Catalog.war
17. Copyright © 2022 Red Hat K.K. All Rights Reserved. Application Server (Tomcat) Service Engine Tomcat設定のおさらい Host Context Host Context 参考 server.xml (サーバ設定) $CATALINA_HOME conf context.xml (デフォルト設定) <Server> </Server> </Service> <Service> <Engine> </Engine> </Host> <Host> webapps logs Review (コンテキスト) Catalog (コンテキスト) WEB-INF classes (プログラム) web.xml (アプリ設定) コンテキスト設定 グローバル設定 Review.war Catalog.war
18. Copyright © 2022 Red Hat K.K. All Rights Reserved. データベース接続の環境変数化 server.xmlやcontext.xmlに定義された外部リソース接続 情報(JNDI: データベースやメールサーバ接続など)を環 境変数に置き換えます。 <Resource 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" /> <Resource factory="org.apache…" name="jdbc/postgres" auth="Container" type="javax.sql.DataSource" driverClassName="org.postgresql.Driver" url="${POSTGRES_URL}" username="${POSTGRES_USERNAME}" password="${POSTGRES_PASSWORD}" /> Pod Container Application Server JVM Pod Container PostgreSQL 環境に依存しないように、 起動時に接続先を指定します * 同一Podの中にSidecarとして異なる役割のプロセスを 置くと、スケールが難しくなるため分離してください。 server.xml or web.xml server.xml or web.xml 改修前 改修後 環境変数化 Review.war
19. Copyright © 2022 Red Hat K.K. All Rights Reserved. 環境変数はApplication Server中に!? <Resource name="jdbc/postgres" auth="Container" type="javax.sql.DataSource" driverClassName="org.postgresql.Driver" url="${postgresdb.url}" username="${postgresdb.username}" password="${postgresdb.password}" /> server.xml or web.xml 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で変数を管理すると、環境変更 のたびにコンテナビルドが必要 変数値設定 接続設定
20. Copyright © 2022 Red Hat K.K. All Rights Reserved. 変数値設定をKubernetesへ委譲 Pod ConfigMap / Secret Container Application Server JVM Review.war (1) 設定ファイルをマウント (2) 環境変数を指定 変数は極小化できる方が運用の効率性は上がります。極力、KISS (Keep it short and simple.)の原則に従いま しょう。 設定ファイル + ファイルだと中身がどう変わったのか分かりづらい + 変更が多い場合はファイル管理のほうが楽 + 変更点が理解しやすい + 変更が多い場合は変数値管理が面倒 Pod ConfigMap / Secret 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をテンプレート化して コンテナをビルドしておく
21. Copyright © 2022 Red Hat K.K. All Rights Reserved. 変数値設定をKubernetesへ委譲 Pod ConfigMap / Secret Container Application Server JVM Review.war (1) 設定ファイルをマウント (2) 環境変数を指定 変数は極小化できる方が運用の効率性は上がります。極力、KISS (Keep it short and simple.)の原則に従いま しょう。 設定ファイル + ファイルだと中身がどう変わったのか分かりづらい + 変更が多い場合はファイル管理のほうが楽 + 変更点が理解しやすい + 変更が多い場合は変数値管理が面倒 Pod ConfigMap / Secret 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をテンプレート化して コンテナをビルドしておく
22. Copyright © 2022 Red Hat K.K. All Rights Reserved. コンテナの環境変数から変数値を取得 Pod ConfigMap / Secret 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: name: postgres_connection key: postgres.url - name: POSTGRES_USER valueFrom: secretMapKeyRef: name: postgres_connection key: postgres.user 環境変数の有効化 - Tomcatの場合 propertiesをホストの環境変数から読み取れるように CATALINA_OPS(or catalina.properties)を設定しておきます
23. アプリケーション プラットフォームの ログ設定
24. Copyright © 2022 Red Hat K.K. All Rights Reserved. Kubernetesのログの取り扱い + アプリケーションに障害が起きるとPodごと消える (可能性がある）ため、障害が起きたコンテナに入り、 ログを見ることができない。 + どのノードでコンテナが動いているか意識しないた め、どこで障害が発生しているのかわからない。 既存のログ管理と異なる点 Pod Container Application Server Review.war stdour/stderr Pod Container Application Server Review.war stdour/stderr Logファイル kubeletはコンテナをログとともに管理します。Podが ノードから削除されると、対応する全てのコンテナが、 ログとともに削除されます。
25. Copyright © 2022 Red Hat K.K. All Rights Reserved. ログの取扱いに関する責任分担 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) + ログに対してフラグが立てられるようにログフォーマット を設定 本資料は こちらが対象
26. Copyright © 2022 Red Hat K.K. All Rights Reserved. ログの取扱いに関する責任分担 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) + ログに対してフラグが立てられるように設定 本資料は こちらが対象
27. Copyright © 2022 Red Hat K.K. All Rights Reserved. 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
28. Copyright © 2022 Red Hat K.K. All Rights Reserved. Tomcatのアクセスログ <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Valve className="org.apache.catalina.valves.AccessLogValve“ directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b" /> </Host> Tomcatのアクセスログは、 org.apache.catalina.AccessLogインターフェイスを実装するValveによって実行されます。 server.xml Pod Container Application Server Review.war stdour/stderr 出力先のファイルを/dev/stdout へ!?!?
29. Copyright © 2022 Red Hat K.K. All Rights Reserved. 標準出力 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
30. Copyright © 2022 Red Hat K.K. All Rights Reserved. Tomcatのアクセスログ <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <!-- combined log format--> <pattern>combined</pattern> </encoder> </appender> <appender-ref ref="STDOUT" /> </configuration> Logback.web <Valve className="ch.qos.​logback.access.​tomcat.LogbackValve"/> LOGBACKはTomcat のクラスを拡張します。 Valveは通常、一緒に関連付けられて処理パイプラインを形成します。 ch.qos.logback.access.​tomcat.LogbackValve を使用するためにserver.xmlに追加 server.xml Pod Container Application Server Review.war stdour/stderr
31. まとめ
32. Copyright © 2022 Red Hat K.K. All Rights Reserved. Server The Twelve Factorの原則にしたがってReplatformを 01 - Replatform (Kubernetesへの移行) 既存アプリケーション (仮想マシンの利用) Server Application Server (Tomcat) Server JVM Application Server Pod JVM Application Server JVM Pod Review.war Review.war Review.war
33. 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.