モノリスなアプリケーションをマイクロサービス化＆AKSに移行……楽天の地道なチャレンジと失敗、成功への道のり【デブサミ2020】

【13-A-5】楽天がモノリス→マイクロサービス & オンプレ→クラウドで経験した光と闇

マイクロサービスとマルチリージョン構成

　マイクロサービス自体は、これまでRailsのroutesから各ファンクションに振り分けていたものを、routesとファンクションを一組にしてポッドに分けて、共通のMySQLに問い合わせる構成にしたという。

　マイクロサービスへの移行を決めた理由について、柳本氏はファンクションのリクエスト量の差に応じた構成を組めること、トラブル時に範囲を特定して影響を最小限に抑えやすいこと、コードがそれぞれ独立していて量も少ないためポッドの起動が速くなること、並列で開発できて工数短縮ができることなどを挙げた。

　マイクロサービスで確実に必要なものは、「間違いなくサービスメッシュ」と柳本氏は断言する。サービスが増えると管理は必須。同社ではIstio＋Helm ver2で運用しているという。そして、ネットワーク周りの可視化では、Kiali（*12）を採用。また、Elasticsearchにログすべてを集約して、Elastic APMのクライアントを組み合わせて監視、オブザーバビリティを高めている。

　デプロイは、Prometheusの情報を引っ張ってカナリアリリース/デプロイ（新機能を一部ユーザーのみに公開し、問題がなければ段階的に全展開するデプロイ方法）を実施するFlagger（*13）を採用。このほか、Kubernetesのステータス監視にPrometheusを活用。「PrometheusからGrafanaに渡してデータをチェック。本番環境に関するアラートはSlackに投げて、ステージングは社内で使っているMicrosoft TeamsにWebhookで飛ばしている」（柳本氏）

*12 Kiali：Service mesh observability and configuration
*13 Flagger：Progressive Delivery Operator for Kubernetes

　ちなみに、Availability Zone構成のAKSにおいて、kubenetでIstioが上がらないトラブルが発生し、現在はAzure CNI（Container Networking Interface）を使っていると柳本氏（*14）。kubenetであればノードにIPアドレスを割り当てて、配下のポッドはNAT変換で処理されるが、Azure CNIではすべてのポッドにAzure仮想ネットワークのサブネットからIPアドレスが割り当てられ、さらに配下のポッドの最大数に合わせてIPアドレスが事前予約される。そのため、IPアドレス不足に陥る可能性があるので、詳細な計画が必要だ。

*14
・Azure Kubernetes サービス (AKS) で kubenet ネットワークを構成する
・Azure Kubernetes サービス (AKS) で Azure CNI ネットワークを構成する

　続いて高可用性構成について、サービス全体はJapan West（JW）とJapan East（JE）のマルチリージョン構成で、Azure Traffic Managerでロードバランシングしていることを説明した。

　「JEではアベイラビリティゾーンを利用、JWはシングルゾーンでAKS（Azure Kubernetes Service）を構成している」（柳本氏）

マルチリージョンでサービスを運用

　これを受けて新井氏は、Azureにおける高可用性構成について説明した。AzureではシングルVM構成、可用性セット、可用性ゾーン、マルチリージョンの4レベルの高可用性構成を提供しており、必要なサービスレベルにあわせて選択できること、また高可用構成における負荷分散やレプリケーションのための様々な機能やサービスが紹介された。

　そして最後は、CI/CDパイプラインだ。

　「GitHubレポジトリにタグを打つとCircleCIが検知してテストを実行（RSpec）、Kanikoでビルドイメージを作成。これをJFrog Artifactoryにプッシュしたら、マニフェストに対してステージングのタグを付与し、AKSステージングにプッシュする。このビルドイメージを使って環境変数をいろいろ調整し、プロダクションにアダプトしている。YAML設定ファイルはkustomizeで管理していて、kubectlの-kオプションで動かしている。カナリアデプロイメント用のマニフェストも、kustomize配下に配置した」（柳本氏）

　以上が、楽天のマイクロサービスの最新状況だ。今後について柳本氏は、次を検討中と述べた。

• マスターデータベースがシングルポイント障害になりがちなので、YouTubeのバックエンドでも採用されている分散型MySQLのVitessを使ってみたい
• メッセージングで、Apache Kafkaよりも運用が楽そうなNATSをデータベースの前に置くような使い方を試してみたい
• オブザーバビリティでは、ユーザーの障害を検知しやすくするため、Open TelemetryとJaegerを組み合わせて使ってみたい
• ポッドやノードなどの障害時の対応に備えて、カオスエンジニアリングを実施したい

　まだまだ試したいことは山盛りのようだ。

　「マイクロソフトでは、Azure上にマイクロサービスを構築する方法（*15）やAKSのBCP/DRのベストプラクティス集（*16）など、役立つ情報が多く掲載されている。ぜひこちらも参考にしてもらえれば幸いだ」（新井氏）

*15 Azure Kubernetes Service (AKS) 上のマイクロサービス アーキテクチャ
*16 Azure Kubernetes Service (AKS) での事業継続とディザスター リカバリーに関するベストプラクティス

お問い合わせ

　日本マイクロソフト株式会社

• コーポレートサイト

• 【クラウドデベロッパーちゃんねる】
  • クラウドを使って開発するITの開発者・デベロッパーの皆様へ様々な技術情報をお届けするYouTubeチャンネル

• 【Microsoft Learn】
  • Microsoft Azureについて学習できる無料のオンライン トレーニング コンテンツ一覧

• 【開発者コミュニティ ニュースレター】
  • マイクロソフトが配信しているニュースレターで、最新テクノロジ記事、技術ドキュメント、および開発者イベントなど、世界の情報を月イチで配信

　楽天株式会社

• コーポレートサイト

• 部署紹介サイト
  • ECに関連するプラットフォームの開発や、フリマアプリのラクマ、楽天ペイ（オンライン決済）などの様々なサービスを行っているECインキュベーション開発部の紹介。東京、大阪、札幌での各種ポジションも紹介しています。