はじめに

　Tutorial Advent Calendar 2020の19日目、Tutorial Advent Calendar 2020の主宰である私SREの平田が投稿をさせて頂きます。よろしくおねがいします。

Tutorial Advent Calendar 2020

今回はSREらしく、インフラ寄りのテーマを選ばせて頂きました。題して「土曜ワイ劇場 Telepresenceの悲劇〜アンチケース〜」です。「悲劇」と書いて「アンチケース」と読みます。紅白にも出場した某大御所声優さんの曲のような難読当て字ですね。

　Telepresenceは、弊社でも開発基盤として導入を検討しているツールです。しかし導入検討時にとある悲劇〜アンチケース〜に遭遇しました。今日はそのお話をしたいと思います。

Telepresenceとは

　TelepresenceはCNCF(Cloud Native Computing Foundation)が主宰するSandboxプロジェクトの一つです。Sandboxプロジェクトはサービス開発の初期段階を支援するツールを集めたプロジェクトで、特にコンテナベースのクラウドアーキテクチャでの開発を推し進めるツールが多く登録されています。

　Telepresence自身は、定義としては「クラウド上のサービスとローカルの環境の間で通信を可能にするためのプロキシツール」です。

　まず、Telepresenceを使うとどんな事ができるのか、実例を通してご紹介したいと思います。例えば、以下のような二重直列のWebサービスがあるとします。

この時サービスBへのリクエストがサービスAから内部IPでのものに限られているとします。その場合、ローカル開発環境や他のネットワークでサービスAだけを立ち上げたとしても、サービスBと結合して開発・検証させることは物理的に難しくなります(言い換えれば、セキュリティが確保されているということですね！)。かといって、その都度マイクロサービスを全てローカル環境や別のネットワークに立ち上げれば、とんでもないコストが必要になります。

　そんな時に活躍するのがTelepresenceです。土曜ワイ○劇場よりも、その間のCMみたいになってしまいましたね。

　ローカルでサービスAとTelepresenceを起動することで、以下のようにクラウド上のサービスAを仮想的にローカルのものと置き換えて使うことができます。

ちなみに先述の図ではDBもクラウド上のものを利用していますが、この点はRDB側の設定次第となります。特定のPod以外からアクセスできる設定があれば、先述の図のように利用することもできます。もちろん、ローカルに立ち上げたDBを設定することも可能です。

　基本的にサービスAを1つのローカルのものに仮想的にすげ替えて事実上専有する形になりますが、swap-deploymentというオプションを変更することで、仮想的にすげ替えるのではなく追加するという形で共有し合うことも可能です。この検証環境や商用環境のような共有環境での利用も可能であるという点こそが、このTelepresenceの最大の魅力の一つです。

　ちなみに、本記事においてこれ以上導入方法には踏み込まないので、もし導入方法が気になる方は以下の記事を参考にして下さい。Telepresenceの導入方法のまとめとしては定番の2記事になります。

• TelepresenceとKubernetesを使って迅速な開発を行う - Qiita
• マイクロサービスのTelepresenceを使ったローカル開発環境の話 - Mercari Engineering

悲劇〜アンチケース〜

悲劇の概要

　弊社のプロダクトのとある部分にTelepresenceを導入しようと思ってシステム構成を図に起こしてみたところ、以下のようになりました。

先程の図と異なる点を箇条書きにすると、以下の3点になります。

• DB(RDB/Firestore)がサービスAとサービスBで共有されている
• RDBがサービスAとサービスBの外にあってTelepresenceの設定だけでは直接参照できない
• 複数人での共有環境である

もしこの状況で無理矢理Telepresenceを利用して環境を立ち上げると、以下のようになってしまいます。

カオスですね。

　最大の問題点はデータ不整合(衝突)です。サービスAでは各自の環境のデータベースがあるので良いのですが、共有されているサービスBでも同じデータベースを参照される前提で実装されているため、データ不整合が発生します。
　上記の図で言えば、サービスBの認識している user_id:1 のuserと、各ローカル環境の user_id: 1 のuserが異なってしまいます。場合によっては、Telepresenceを使わずサービスAとサービスBを利用していた user_id: 1 のuserもいるかもしれません。

　まさに悲劇〜アンチケース〜です。

悲劇の原因分析

　このアンチケースの原因は、1つに収束するものではありません。原因の組み合わせによるものです。言ってしまえば、相性問題です。

　軸として、Telepresenceで置き換えたいサービスが「専有しても問題ない環境(以下 専有可能環境)」であるか、はたまた「専有することができない共有環境(以下 共有環境)」であるかが重要になります。どちらでも、状況次第ではTelepresenceで置き換えて利用することが可能です。

　もう1つの軸が、対象のサービスとほかのサービスにおいてデータ等に依存性がある密結合であるか、そうでない疎結合であるかです。

　まず、専有可能環境かつ他のサービスと疎結合なサービスである場合は、Telepresenceで置き換えて利用することが可能です。その際、専有することも可能ですし、サービスで密結合な部分が存在しないのであればデータ不整合等も発生しないため、複数人で共有することも可能です。

　専有可能環境かつ他のサービスと密結合なサービスである場合は、Telepresenceで置き換えて利用する事自体は可能ですが、データ不整合を防ぐために必ず専有する必要があります。最低限データの結合を削除してデータ周りだけでも疎結合にしない限りは、共有して使うことは難しくなります。

　共有環境かつ他のサービスと疎結合なサービスである場合は、Telepresenceで置き換えて利用すること自体は可能ですが、当然ながら専有しないようswap-deploymentを調整する必要があります。

　共有環境かつ他のサービスと密結合なサービスである場合は、そのままではTelepresenceで置き換えて利用することができません。専有可能な環境にするか、データ周りだけでも他のサービスと疎結合な状況にしない限りは、何かしらの不都合が生じてしまいます。

結び

　Telepresenceは導入も簡単で非常に便利なツールですが、一方で利用対象サービスの構造によっては導入が不可能な場合もあります。そして、そういったTelepresenceをすんなりと利用できないサービス構成は、改修コストのかかりがちな状況に陥りやすいとも言えます(特にデータ周りで密結合な部分が存在するサービスでは著しいと思います)。

　今回のような開発環境の整備を機に、アーキテクチャ全体を見直してみてはいかがでしょうか？