（左）原 伸樹さん（右）横田 大樹さん（ともにシステム研究開発センター所属）
～品質の高いクラウドネイティブなシステムを開発することこそ、システムインテグレータとして私たちがクラウドネイティブに取り組む意義がある～
デジタルトランスフォーメーション（以下、DX）を進める企業が増えるにつれ、従来とは要求の異なるシステム構築が求められるケースが増えてきました。従来との違いは大きく2点。1つ目は、開発手法がウォーターフォールからアジャイルになったこと。もうひとつは、システムのインフラ環境がオンプレミスからクラウドに変わりつつあることです。
このような流れを受け、当社のシステム研究開発センター（以下、シス研）では、クラウドネイティブなシステムの研究に着手しました。
クラウドネイティブなシステムを実現する上での課題とは何か。その課題を解決する技術やソリューションは何か。シス研 原 伸樹さん、横田 大樹さんに話をお聞きました。
クラウドネイティブなシステムをテーマとした研究を開始
―― クラウドネイティブなシステムとはどういうシステムですか。
横田：クラウド上にあるシステムではありますが単にそれだけでは「クラウドネイティブなシステム」とは言えません。「クラウドネイティブなシステム」にはCloud Native Computing Foundation（CNCF）で定められた定義※1があります。
※1 CNCF Cloud Native Definition v1.0
―― どのような定義ですか。
原：CNCFの定義では、クラウドの基盤の上でコンテナ、マイクロサービス、宣言型APIを用いて疎結合なシステムを構成することで、開発の「アジリティ」と「スケーラビリティ」の獲得を実現しようとする考え方です。さらに非機能面においても回復性や可観測性、自動化といった特性をもっているものと謳われています。これは、単純にクラウドを使うだけではなく、これらの非機能的な特性を意図的に作りこまなければならないことを意味しています。
―― クラウドネイティブなシステムの動きが始まったのはいつ頃ですか。
横田：コンテナ及びその周辺技術、特にkubernetesがコンテナオーケストレーションのデファクトになった2016、2017年あたりからです。日本でもアーリーアダプタを中心に活発な動きがあります。
―― 原さんや横田さんはクラウドネイティブについて、いつごろから研究を開始されたのですか？
横田：2015年よりコンテナをはじめとした個別要素技術の技術担保に取り組んでいましたが、「クラウドネイティブなシステムの構築」を目的に掲げ、研究テーマを取りまとめ、推進し始めたのは今年度（2019年度）からです。
原：私たちのグループはこれまでパブリッククラウド活用技術とシステム性能管理技術※2をテーマにそれぞれ別チームで研究を続けてきたのですが、今後はクラウドネイティブなシステムを要望されるお客様が増えてくると思い、私たちのグループ全体ではこれまでの研究テーマを発展させる形でクラウドネイティブ開発・運用技術という方向に舵を切りました。
※2（参考）以前テックコラムでご紹介した関連記事
次世代企業システムを性能面から支え続ける～NSSOLの強みと性能管理の潮流～
―― 今後はクラウドネイティブなシステムが主流になっていくのでしょうか。
原：いわゆる従来型のシステムのように、要件が明確で、変化への柔軟で高速な対応よりも非常に高い可用性が重要なシステムは、これまで通りウォーターフォールでつくるでしょう。まだまだそうしたシステムは多いので従来型のシステム開発は残っていくと思います。とはいえ、長期的な視点で見た場合、2018年に政府が発表した「クラウド・バイ・デフォルト」方針にもあるように、クラウドを中心としたシステムが主流になっていくことはほぼ間違いないと思います。
クラウドネイティブなシステムでは障害に対する考え方が違ってくる
―― では、クラウドネイティブなシステムと相性がいいのはDXですか？
原：そうですね。クラウドネイティブの特性はDXプロジェクトでよく採用されるリーンスタートアップ的な手法やアジリティの高い開発スタイルなどにマッチしています。さらにひとたびビジネスが成功すればスケーラビリティが必要になってくる。
―― 従来のシステム開発と違う点はアジリティとスケーラビリティですか？
横田：その2つを最優先させます。機能を改修したり新しい機能を追加したりするときに、今までのやり方だとお客様が要望するスピードに全然追いつかないのです。お客様は自社で開発したサービスを常に改善しながら早くビジネスを成長させたいですから。
原：アジリティとスケーラビリティを優先させると障害に対する考え方が違ってきます。従来はシステム品質重視で、ハイエンドなインフラで構成された、落ちないシステムをつくってきました。しかし、そのようなシステムを構築するには多くの時間と費用が必要となりアジリティを阻害します。そのためクラウドの世界では、システムはダウンする前提で、セルフヒーリングを実現するコンテナ基盤やアプリケーション側でフォールトトレランスを実現するなどして、アジリティを阻害しない形でシステムに回復性を持たせる考え方が定説です。
―― 米国的な考えですね。
原：私たちは、SIerとしてアジリティやスケーラビリティを優先しながらも、長年培ってきたエンタープライズにおけるシステム開発実績を活かしながら、高い回復力を持つ高品質なクラウドネイティブの実現を目指しています。それこそが私たちがクラウドネイティブをやる意義だと思っています。
クラウドネイティブなシステムに必要なもの「可観測性」
―― 先ほどの「アジリティやスケーラビリティを優先しながらも、品質も高いシステム」のために必要なことはどんなことですか？
横田：1つの要素として、「可観測性」が必要です。
―― 可観測性？それはどのようなものでしょうか？
横田：以前からシステムの異常にすぐ対応できるよう注意深くモニタリングを行ってきました。一方でこれまではシステムのリリース前のテストをしてどこにボトルネックがあるかわかっていたので気を付けるべきポイントはある程度予測できていました。そのボトルネックの箇所を注意深くモニタリングさえしておけば、多くのトラブルは防げたわけです。
一方、クラウドネイティブなシステムではシステムはエンドユーザーのニーズにあわせ次々と機能が変更・追加されシステムも拡張していきます。更に大きなアプリケーションを、メンテナンス性を考えて小さく分割して疎結合にしてより分散型のかたちをとるマイクロサービスで開発される場合もあります。そうなるとボトルネックが事前に予想できない状態になります。
―― ええ。
原：ボトルネックをいかに迅速に把握できているか。言い方を変えれば、システムの状況を、事細かな深い部分までいかに人がシステムから正確な情報を取得し、迅速に適切なアクションにつなげられるか。この性質のことを「可観測性」と言うのですが、クラウドネイティブなシステムにおいては、この可観測性を担保していることが必須となってきます。先ほどいったCNCFのクラウドネイティブの定義にも可観測性の具備はクラウドネイティブが持つべき重要な性質として明記されています。
―― 可観測性を実現するためにはどうすればいいのでしょうか？
原：従来のメトリクスやログの取得に加えて「分散トレーシング」という技術を用います。
―― 分散トレーシング？
横田：先ほどマイクロサービスの話をしましたが、マイクロサービスだと複数のサービスが連携して、例えばAが処理をしたら次にBに処理を投げて次にCに投げてという形で一連の業務処理が実行されます。この時にある通信が失敗した時に、この通信はどこのサービスをどういう順番で経由していったのかがわからないと何がどうおかしくなったのかわからなくなってしまいます。その処理全体のつながりをトレースするために必要な技術が分散トレーシングになります。
分散トレーシングを実現するソリューション「INSTANA」
―― 分散トレーシングを行うツールはあるのですか？
原：はい。私たちが実際に導入したのが「INSTANA（インスターナ）」という製品です。
―― INSTANAの特徴を聞かせてください。
横田：従来の監視ツールでも、CPU使用率のようなメトリックやアプリケーションから出力されるアプリケーションログ、ある1サービス内の処理内容はモニタリングできました。ただ、先のマイクロサービス同士の連携部分、サービスをまたぐような全体の処理フローについては、分かりませんでした。言ってみれば、断片的な情報だったわけです。
複数のサービスA, B, Cが連携している場合、どのサービスが遅延したのか。それらのサービスはどのインフラに配置されていたのか。インフラのリソース使用量はどうだったか。その時どのようなログが出たのか。それらを関連付けて把握できていなかったからです。システムが厳しい状態にあることは分かった。でもどこが具体的には悪いのかは、すぐには分からない。これが、以前の状況だったわけです。従来の監視ツールでは、ただ個別の事象をそれぞれのツールが報告するだけでした。
原：一方、INSTANAであれば、サービス間のトレースとそれらサービスが動作していたインフラの状態をシームレスに確認できます。ここが、従来の監視ツールとは大きく異なる点です。
Instana社のDevOpsロボットキャラクター STAN君
エージェントをOSにインストールするだけ。あとは自動でシステム全体の構成から動きまでを随時監視
横田：さらにINSTANAが魅力的だと感じるのは、多くのことを自動でやってくれる点です。以前の監視ツールの場合は、モニタリング対象毎にインストールや数多くの設定が必要なことが多く、また一般的な分散トレーシングのライブラリを用いる場合、実運用化するためにアプリケーションコード自体にトレーシング情報を出力するためのコードを開発者自身の手で挿入する必要がありました。
一方、INSTANAは、利用者はただエージェントをインストールするだけ。あとはエージェントが分散トレーシング用のコードを自動でシステムを挿入して勝手にモニタリングを開始していきます。またINSTANAのバックエンドはSaaSで提供されユーザーは監視システムを一から構築する必要はありません。
エージェントをインストールすると、まずはシステム全体の構成情報を認識してくれます。監視対象のサーバーの数ならびに属性、さらにはどのサーバーでどのアプリケーションが動いているのか。複数のサービスがどのように互いに通信しどれくらいの時間で処理を実行するのか、まさに私たちが知りたい情報を、GUIで示します。
原：構成の自動検出はアプリケーションの導入時だけではなく更新時も有効であり、利用者には監視に関する設定変更作業が伴いません。INSTANAがシステム改廃箇所を自動で検知しその後は最新の構成に対して自動で追随していきます。
―― システムの運用管理者にとっては、とてもありがたいツールですね。
原：データの取得粒度も優れています。以前の監視ツールでは10秒に一度程度でしたが、INSTANAの場合は1秒に一度ほどですからね。
アラート機能もついていて、問題が生じそうなサービスに異常が見受けられると、利用者に知らせます。
―― それは、どのあたりが“ありがたい”のでしょう。
原：特にウェブサービスなどの場合、ユーザーへの応答速度の遅延がサービス品質に直結するためモニタリング対象にすることが多いのですが、従来は人がそれに気づけるようにアクセスログやシステムリソース利用量などに個別の閾値を設けてアラート設定するのが一般的です。ただやみくもにこれを行うと、場合によってはアラートが大量に発報されることになり、結局人がその重要度を選り分けることになりがちです。INSTANAはREDメソッド※3に則りサービス品質に影響する指標の異常に対してのみアラートを発報します。アラートを受信した人からするとサービス品質の異常に基づいたトップダウンでの分析が可能になりアラートの選り分け作業から解放されます。
※3 REDメソッド
R=Request（要求リクエスト数）、E=Error（エラー率）、D=Duration（リクエスト処理の時間）の3つの指標名の頭文字をつなげてそう呼んだもの。マイクロサービスにおいて、測定しなければならない指標とされている。いずれもサービス視点であることが重要。
横田：実はログ、メトリック、トレースとこれら3つの指標を有機的に繋げて監視・分析することは、技術的にかなりハイレベルです。システム全体を隅から隅まで監視しているわけですから、ふつうに考えれば、システムへの負荷が大きくなることは、明らかです。
ところがINSTANAの場合は、システムへの負荷はほとんどありません。計測ポイントを最小限にしたり、独自の技術でデータを圧縮し、大部分の処理をバックエンド側で実現しているからです。
柔軟でありながら高い信頼性を持つクラウドネイティブなシステムを構築できるSIerとして存在感を発揮していきたい
―― 導入実績も既に沢山あり、お客様からも好評だと聞いています。
原：既に15社ほどのお客様に導入しており、クラウドネイティブなシステムを運用されているお客様、また従来型のシステムを運用されているお客様からも有効なソリューションだと高い評価を得ています。
―― 具体的にどのようなお客様に導入したのか、教えていただけますか。
原：あるCMSのパッケージ製品でアプリケーションを構築されているお客様のケースを挙げると、そのアプリケーションへのアクセスが10回に1回ほどの割合で動作が遅くなることがありました。パッケージに問題があるのか、あるいは自社のアプリケーションなのか調べてほしい、とのことでした。
INSTANAを使うとCMSに問題があるとすぐに分かりました。
横田：IoT機器を数多く設置すると共に、それらの端末から大量のデータが常にサーバーに飛んでくるような大規模データ処理基盤を持つ製造現場などでも活躍しています。
端末は次から次に増えながらバックエンド側のマイクロサービスも増えていくため、システムの管理担当者も、システム全体を把握できていない状況でしたが、INSTANAを入れたことでシステム全体が把握できるようになりました。
そして実際に分散トレーシングを開始すると、データベースサーバーに大量のアクセスが集中していることが検知され、チューニングする必要があるといった課題を得ることもできました。
―― 今後の展開はいかがでしょう。
原：大きくは二段階のフェーズを計画しています。
1つ目は、事例を増やすこと。新規・既存のお客様に限らず、これまでの監視や運用で生じていた問題やトラブルを、INSTANAを導入することで解決していくことを実感して頂きたいです。
実は既にINSTANAの導入に関してのPoCサポートや、運用時のコンサルティングを行っています。また導入後のフォロー体制も整備し、よりタイムリーで高品質の問い合わせ対応を実現できる体制を整えました。
2つ目は、フェーズ1で実現した可観測性の高いシステムに対する運用改善を体制面、プロセス面で整備していきたいと考えています。クラウドネイティブなシステムを正しく運用していくためには、ツールの整備だけでは不十分です。クラウドネイティブの実現には開発・運用双方においてアプローチが変わる部分も多く、そのため人のマインドも変えていかないといけない部分も数多くあります。我々は、システム開発だけではなく、人の体制も含めたプロセス改善の部分においても、ソリューションを提供していかねばと思っています。
―― 今日はどうもありがとうございました。
