KubeCon 2日目の注目はAirbnbのユースケースとBallerina

連載 [第4回] :

KubeCon＋CloudNativeCon Seattle 2018レポート

2019年1月25日(金)

KubeCon＋CloudNativeCon 2日目のセッションから、Airbnbのユースケースと、クラウドネイティブ志向の言語Ballerinaを紹介する。

KubeCon＋CloudNativeConの2日目の注目は、キーノートで行われたAirbnbのユースケースだろう。KubeCon Chinaでも見られた傾向として、そもそもKubernetesそのものの話はすでにピークを過ぎており、どのようなツールを使って自社のインフラストラクチャーやアプリケーション実行環境、開発環境を自動化するか？　という部分に注目が集まっていた。Kubernetesは習得するためのコストが高いというのは、多くのエンジニアが認めるところだが、今回のカンファレンスでもKustomizeやTilt、Atomist、Pulumiなどのツールの解説や、自社でツールを開発しKubernetesをラップして抽象化する方法などが、様々なセッションで解説されていた。

それ以外ではサービスメッシュとサーバーレスが新しいパラダイムとして注目されており、サービスプロキシーのEnvoy、その上で稼働するIstioという2つのソフトウェアはIBM、Cisco、Red Hat、Google、AWSなどの錚々たるベンダーが貢献していることで耳目を集めている。実際EnvoyとIstioは、サービスメッシュ関連のセッションでは必ずと言っていいほど登場するほどの位置付けになっていたように思える。またKnativeも、Red Hatが開発コミュニティに本腰を入れることが発表されたこともあってか、多くのセッションで言及されるなど、大きな流れになる予感を感じたカンファレンスとなった。

今回のレポートでは、Airbnbのキーノートと、Red HatのChristian Posta氏によるマイクロサービスとそれを実装する言語としてBallerinaを紹介したセッションを紹介する。

Airbnbが解説したマイクロサービス化のユースケース

AirbnbのMelanie Cebula氏

AirbnbのMelanie Cebula氏によるセッションは、自社のマイクロサービス化において直面した問題点をどのように解決したのか？　という内容だ。モノリシックなアプリケーションからマイクロサービスに移行する際に、オーケストレーションのプラットフォームとしてKubernetesを採用したというのは、もはや当たり前に聞こえるが、多くのデベロッパーにとってkubectlを使わせるのはコストが高く、構成ファイルであるmanifestも多数必要になることを指摘する。

似たようなKubernetesの構成ファイルが多数発生する問題

そのためAirbnbでは、GitOpsに倣って全ての構成情報、ソースコードなどをGit上に管理し、そこから自社製のKube-genというツールで本番環境、カナリアテスト用環境、開発環境のそれぞれの構成情報を生成することにしたという。この辺りの発想はサイバーエージェントが社内のエンジニア向けにKubernetes-as-a-Service（KaaS）を作ろうとしたということと通底するものだろう。Kubernetesが良いのは分かるが、もっと抽象化して簡単にしたいというニーズは、これからも多くの企業で様々なツールの開発に繋がっていくと思われる。そして最終的には、少数のツールに収束していくのではないだろうか。Airbnbのセッションを聞いて感じたのは、そんな過渡期の真っ只中にいるという感触だった。

参考：Japan Container Daysのキーノートで語られたCA、ヤフージャパン、メルカリの事例

Kubernetesの構成ファイルのテンプレート、Airbnb的に言えばBoilerplateの削減については、Airbnbとしてもいくつかのオプションを検討したようで、HelmやKustomize、Kapitanなどが挙げられていた。

Airbnbで検討された構成ファイル過多問題に対するツール

またCI/CDについても、デベロッパーがAWS上のクラスターにデプロイするまでを一気通貫で行えるようになっているなど、DevOpsという用語は使わないものの、実際に開発から運用までを連続して行えるように工夫されていることが紹介された。

詳しくは以下のセッションの動画とスライドを参照されたい。

Airbnbのキーノートセッションの動画：Developing Kubernetes Services at Airbnb Scale - Melanie Cebula, Software Engineer, Airbnb

スライド：https://schd.ws/hosted_files/kccna18/1f/kubecon%202018.pdf

マイクロサービス志向の言語Ballerina

次に紹介するのは、サービスメッシュとそれを実装するBallerinaと言う言語に関するセッションだ。スピーカーはRed HatのChrtistian Posta氏で、タイトルは「Evolution of Integration and Microservices with Service Mesh and Ballerina」というものだ。アプリケーションがサービスメッシュを利用する際の留意点などを紹介した後に、言語レベルでサービスメッシュを実現するBallerinaを解説するという構成だ。

Ballerinaとサービスメッシュを使ったアプリケーションインテグレーション

参考：クラウドネイティブなプログラミング言語Ballerinaとは？

Christian Posta氏は、Red Hatが2012年に買収したFuseSourceのエンジニア出身で、Apache CamelやJBoss FUSEなどのエンジニアを経て、現在はCloud Application Developmentグループのチーフアーキテクトである。

マイクロサービスとレガシーなシステムの連携は必要

まずPosta氏は、マイクロサービスによる新しいアプリケーションが出てきたとしても、すでに持っているレガシーなアプリケーションやシステムは捨てられない、だからそれらと連携する必要があるというエンタープライズ企業なら当たり前のことを再確認した上で、マイクロサービスになった際に抜け落ちがちな留意点は、「システムに付随する複雑さがサービスとサービスの中間に存在するようになってしまうこと」だと解説した。

サービスの間に複雑さが入り込んでしまう

一例としてECサイトのショッピングカートのシステムが取り上げられた。ここではブラウザーから来たリクエスト「カートに品物を入れる」を処理する際に、カートのアイテムの更新とともにレコメンデーションを行うサービスに情報が飛び、カートの内容に従って最新のオススメを提示する、という処理を解説した。

ECサイトを例にサービス連携を解説

これだけでも、複数のサービスが連携していることは誰でも理解できるだろう。ポイントとなるのは、アプリケーションが連携する際にメッセージの並列化、シリアライズ、エラー処理などをどこかで行わなければならない点だ。それはプログラムを書くデベロッパー側の責任なのか、それともインフラストラクチャーやミドルウェアなどを管理する運用側の責任なのか、あやふやになってしまうという点を指摘している。

アプリケーション連携の留意点

そしてアプリケーションがネットワークを構成する際に必要となるサービスディスカバリーやロードバランシング、タイムアウト、リトライ、サーキットブレーカーなどの処理は、明確にアプリケーションデベロッパーの責任であると解説した。

アプリ間ネットワークの処理はデベロッパーが責任を持つべきと断定

より正確に記述すれば、「分散型システムにおいてアプリケーションが安全に正しく処理を行うことは、アプリケーション開発チームの責任である」ということだ。

エラー処理やリトライなどはアプリケーション開発チームの責任

そしてそれを可能にするソフトウェアとして、Posta氏はWSO2が開発をリードするオープンソースのプログラミング言語Ballerinaを紹介した。

Ballerinaの紹介

Posta氏が強調したのは、Ballerinaが並列的なネットワークサービスの記述を最優先に考えて作られた言語であり、特にシーケンスダイアグラムの生成を実現していることを紹介した。

シーケンスダイアグラムを表現することが基本機能として備わっている

その例を示したのが次のスライドだ。

Ballerinaが生成したシーケンスダイアグラムの例

Posta氏も説明しているが、通常であればデベロッパーがシーケンスダイアグラムを書いた上でそれをソースコードに書き起こすという順序になる。その点Ballerinaには、ソースコードを記述すると同時に、対応するシーケンスダイアグラムを生成することが基本機能として備わっている。結果として、サービス間連携のパターンであるサーキットブレーカーやバルクヘッド、リトライなどの機能を、ソースコードで記述できるというのがBallerinaの特徴だ。

サービス間連携のデザインパターンを実装できる

ここでPosta氏は、マイクロサービスのデザインパターンを実装したオープンソースソフトウェアとして、NetflixのHystrixを紹介する。ここでは多くのデザインパターンが実装されたが、主にJavaをベースとしているとして言語に依存する欠点を指摘。

NetflixのOSSを紹介

そこからOperabilityという言葉を用いて、アプリケーションサービスがエラーなどを乗り越えて運用できることが最も重要な優先度になっていることを語った。つまり多数のサービスで構成されるクラウドネイティブなシステムにおいて「様々な障害や遅延などがあったとしても、ユーザーエクスペリエンスとしてちゃんと動くこと」を保証することが、デベロッパーにとっての優先項目になっていることを説明したと言える。

Operabilityが重要

Envoy＋Istio

それを言語に依存せずに可能にするソフトウェアとしてEnvoyを紹介した。ここからはEnvoyそしてIstioの紹介を行った。

Envoyの紹介

EnvoyはLyftが開発をリードする軽量のProxyサーバーだ。KubernetesのPodの中に配置されるサイドカーパターンを使うことで、多数のPodが連携して動くサービスメッシュの場合において、サーキットブレーカーなどのデザインパターンの実装、メトリックスの取得などを可能にするソフトウェアだ。

Envoyの概要。Podに配置されてPod間の通信を代行する

そしてサービスメッシュは、Ballerinaが実現していたサービス間連携においてほぼ同様の機能を提供すると解説。

サービスメッシュが実現する機能

続けて、サービスメッシュを実現するソフトウェアを紹介。Istio、Consul Connect、Linkerdなどについて簡単に解説した。その後、同じ機能を実装するソフトウェアが複数存在することについても言及し、プラットフォームとしてはKubernetesとRed Hat版のKubernetesであるOpenShift、サービスメッシュとしてIstio、Envoy、さらに上位のアプリケーション開発言語としてBallerinaを紹介した。ここでPosta氏は、どれが良いということではなく、今の時点では多くのオーバーラップが存在しており、それをデベロッパー、インフラストラクチャーエンジニアが選択するしかないと説明。

サービスメッシュのインフラから開発言語までを俯瞰

そしてこのセッションの結論として、以下の項目を提言した。

サービスメッシュをサービス間連携の主要なテクノロジーとして利用すること
サービス間連携のワークフローを最初からデベロッパーが考慮すること
言語に依存する実装を使うことは最低限にすること
アプリケーションロジックとして実現されるべきことをサービスメッシュの機能に持ち込まないこと
アプリケーションとサービスメッシュの境界線を守ること

Posta氏の提言

今回のセッションでは、アプリケーションをマイクロサービスとして構成する際に、デザインパターンをどこに持たせるのか？　それの責任は誰が持つのか？　という問題点について一つの回答が与えられたと思える。Ballerinaはソースコードレベルでそれを実装し、IstioはEnvoyを使って実装する。どちらのテクノロジーを選ぶとしても、それについてはデベロッパーが責任を持つべきだというのがPosta氏の意見だ。

これについては、Red HatでFuseを開発していたエンジニアの言葉だと思えばその重みも理解できるだろう。もちろん、Pivotalのように12ファクターアプリを提言しているベンダーの意見も聞いてみたいところだし、パブリッククラウドベンダー各社もそれぞれの意見があるだろう。この辺りの判断については、今後出てくる多くのユースケースを持って行うこととなるだろう。今から、来年のKubeConが非常に楽しみになるセッションとなった。

Christian Posta氏のセッションとスライドについては以下を参照されたい。

参考：Evolution of Integration and Microservices with Service Mesh and Ballerina - Christian Posta

スライド：https://schd.ws/hosted_files/kccna18/49/kubecon18-ceposta.pdf