text：小山 賢太郎 日本IBM
山本 和美 日本アイ・ビー・エム システムズ・エンジニアリング
本章では、デジタルサービス・プラットフォーム基盤（以下、DSP基盤）のコンポーネントを利用せずに、DSP基盤のアーキテクチャ・設計をリファレンスして、コンテナ基盤環境を構築した事例を紹介する。
DSP基盤をリファレンスした経緯
本案件は、IBM Cloud上の既存環境（IBM Cloud Bare Metal Servers）を拡張する形で新規コンテナ基盤環境を構築した事例である。エンドユーザーが利用開始するまでの期間が通常より短く、高可用性でセキュアなコンテナ基盤環境をいち早くお客様に提供する必要があった。
そこで、IBM Cloudがマネージドサービスとして提供しているRed Hat OpenShift on IBM Cloud（以下、ROKS）を採用した。また先行して設計が進められていたDSP基盤のアーキテクチャ・設計をリファレンスし、お客様の要件にあわせてカスタマイズすることによってスピードと品質の両立を図ることとした。
クラスター戦略
IBM Cloudのアベイラビリティ・ゾーン（以下、AZ）単位での障害やクラスター自体の論理障害に備えて、OpenShiftの構成を検討するクラスター戦略は重要である。本事例では、クラスター戦略を決定する際に、DSP基盤のアーキテクチャをリファレンスした。
図表1に示すとおり、2つのクラスター構成を検討し、それぞれ耐障害性・運用コスト・資源コストの観点から評価した。
どちらもAZ障害影響を受けづらい構成であるが、クラスター自体の論理障害に対して耐障害性が高いのはMultiple Cluster構成である。一方、複数クラスターを保持することで運用・資源コストの増加が懸念されたが、ROKSにおいてMaster Nodeはマネージドかつ資源コストが不要であったため、影響は軽微であった。DPS基盤においても標準でMultiple Cluster構成を提供していることもあり、本事例でも同構成を採用した。
ログ外部転送手法
クラスター戦略に加え、クラスターからログを外部転送する手法についても、DSP基盤での手法を標準として採用した。そのうえで、お客様要件を充足できないポイントについて、独自でログ外部転送手法にカスタマイズを加える方針とした。カスタマイズ内容については後述する。
DSP基盤のアーキテクチャをリファレンスし検証済みのログ外部転送手法を標準として採用することで、設計・検証工数削減と品質向上を実現できた。また今後、不具合や障害が発生した際にもDSP基盤と情報交換することによって迅速な対応が可能になる効果も期待できる。
ログ設計のカスタマイズ
DSPは複数の金融システム会社用に共通化させたシステム設計であるため、アプリケーション・コンテナのログは標準出力のみを取得、保管している。本事例においては、アプリケーション・コンテナが出力するログをシステムの状況確認や障害時リカバリ対応に使用するため、ログをロストしないように保管する必要があった。また、本事例で稼働するアプリケーションは、サーバー向けアプリケーションを移行したものであったため、ログは「標準出力」「ファイルに出力されるログ」「バイナリー形式のログ」の3種類が存在した。
このような要件のなかで、特に「①ログをロストしない」、「②バイナリー形式のログ対応」をカスタマイズのポイントとして記載する。
①ログをロストしない
標準出力以外のコンテナ内ファイルに出力するログがあるため、当初はアプリケーションと同じPod内にコンテナを同居させるSidecarとしてFluentdコンテナをアプリPod内に配置し、コンテナ用非永続ストレージのemptyDir上に作成されたログ・ファイルをFluentd経由でログ・サーバーに集約させる予定であった。
しかし、emptyDirは特定のタイミング（Pod削除、もしくは別Nodeへの移動）で削除される。ログをロストしないためには、Podが削除されてもログはFluentdで移動されるまでのある程度の時間は削除されない必要があった。
IBM Cloud Classic InfraにおけるROKS4で使用可能なStorageを図表2に示す。
ROKS内で長期に保存する必要はないため、永続ストレージではなく、非永続ストレージを選択した。しかし、Podが削除されたとしても、ある一定の時間はログを保管するために、ストレージをemptyDirからhostPathに変更することとした。
hostPathに変更することで、図表3のようにPod内にSidecarでログ転送しなくても、各Node上のDaemonSetで配置したFluentdからhostPathのディレクトリをマウントし、ログ・サーバーへ転送する方法に変更することができた。
この変更により、アプリのdeploy用yamlの変更時にインフラ側の対応が不要となる。また、アプリPod毎ではなく、Nodeに1つのみFluentdのPodを配置すればよいため、リソースの使用削減にもつながった。
②ログがバイナリー形式
Fluentdはpluginを追加することで、ログの形式や出力方法などに対応するようになっている。ログは基本アスキー形式を想定しているため、pluginもアスキー形式に対応したものがほとんどである。
しかし、本案件のログはバイナリー形式が存在した。バイナリー形式にFluentdを対応させるためには、pluginの開発から始めねばならず、今回は断念した。Fluentdを使用せずログを保管する方法として、図表4で示すようにログを外部ディスクに保管し、そのディスクをログ・サーバーからもマウントする設計に変更した。
オンプレミスからの移行の課題
本案件では、オンプレミスで稼働させていたアプリケーションをコンテナ化し、サービス提供するものであった。単にコンテナ・イメージに変更するだけでは対応できず、コンテナ特有の課題も発生した。今回遭遇した主な課題を以下に記載する。
・ログがでない！
このアプリケーションはC言語で作られており、ログの一部をSYSLOGライブラリを使用して出力していた。一般的に、コンテナ・イメージはできるだけ軽量にする、という認識があり、本事例においても一番軽量なBase Imageを採用していた。しかし、そのBase Imageにはrsyslogが含まれておらず、ログをsyslog経由で標準出力の/dev/stdoutに出力させることができなかった。
アプリケーション側でSYSLOGライブラリを使用せずにログ出力を可能にする改修がプロジェクト期間内では難しかったため、journaldとrsyslogを含むBase Imageに変更し、rsyslog経由で標準出力にログを出力させ、コンテナ外部に保管可能とした（図表5）。
・パフォーマンスがでない！
一般的にコンテナは機能別にアプリケーションのコンポーネントを分割し、それぞれを疎結合させるべき、と言われている。一方オンプレミスのアプリケーションの場合は、すべてのコンポーネントを1つにまとめ、最良のパフォーマンスになるようにチューニングされることが多い。本案件では、アプリケーションを分割し、それぞれ別コンテナとして起動、連携させる予定であった。
しかし、コンテナ化したアプリを連携して稼働させてみると、CPU使用率が増大し、想定のアクセス量に対応することができなかった。
コンテナにsysdigやsar、straceでパフォーマンス情報を取得、解析をおこなったところ、I/O周りのシステム・コールが増大していることが判明した。アプリ・コンテナ間通信を共用メモリで実施していたのだが、そこが原因との仮設をたて、お客様に対応を依頼した。
図表6で示すように、Podとコンテナをオンプレの時と同様に1個に集約すると、CPU使用率が低減し、パフォーマンスが改善した。
このように、アプリケーションをコンテナ分割することで、今までの最適化チューニングが効果を出さないことがある。そのための問題解析にはコンテナの知識だけでなく、今まで培ってきたパフォーマンス解析のノウハウも必要とされた。
DSP基盤のアーキテクチャ・設計をリファレンスし、お客様要件を取り入れるためのカスタマイズ事例を紹介した。DSPの設計やノウハウをもとに、クラスター戦略として取り入れた部分、本案件独自のアプリケーションで発生した、ログ対応やパフォーマンス問題について述べた。
エンタープライズ領域におけるコンテナ基盤の活用は、現在積極的に進められている。今後も多くのリファレンス・アーキテクチャの公開やノウハウの共有が進むと考えられる。本稿が今後のプロジェクトの参考になれば幸いである。
小山 賢太郎 氏
日本アイ・ビー・エム株式会社
グローバル・テクノロジー・サービス事業部
アソシエイトアーキテクト
クラウド・コンテナ・自動化を得意分野とするエンジニア・アーキテクト。近年は、主に金融業界のお客様、クラウド・コンテナを活用したソリューションの提案・構築活動に従事している。
山本 和美氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・プラットフォーム
シニアITスペシャリスト
入社以降、さまざまな業種のオープン系システムの構築やアセット化に関わる。近年は主に、OpenShift、コンテナ、クラウドをメインとした技術支援を担当している。
DSP冒険の書 Contens
0章 はじめに ～発表から1周年を迎えたDSP
1章 ログ管理システムの構築
2章 ジョブ管理システムの構築
3章 クローン環境の構築
このサイトの掲載内容は著者自身の見解であり、必ずしもIBMの立場、戦略、意見を代表するものではありません。
［i Magazine・IS magazine］
