【イベントレポート】SB Tech Night #5 プロのエンジニア達がクラウドサービスの知見を披露！

■「GKEバージョンアップ　サービス影響 Zero？」

続いてのスピーカーは、ソフトバンク株式会社　サービス開発部の李尚弦氏。 サーバエンジニアとして10年目の李氏の現在の主な業務の内容は、サービス開発、維持管理、自動化、DevOps、R&Dなど多岐に渡ります。

GKEバージョンアップはサービスに“本当に影響がないか？”というテーマで発表を行いました。今回の資料は、弊社のサービス開発部で初めてGKE上にサービスを開発したとき、経験した問題と対策についてまとめた資料になります。

最初に前提として、GKEバージョンアップを行ったサービスの状況を説明しました。

「提供サービスは、弊社データセンターではお客さんへのオンプレでサーバ・NW機器を提供していて、そのログデータをクラウド上に保存し、エンドユーザがダウンロード、検索できるようにサービス機能を提供しています。簡単なサービス構成と処理フローは以下の通りです」

サービス構成と処理フロー

1.ログ転送サーバからLBへsyslogにてリアルタイムでログ転送

2.LBからPod（コンテナ）へトラフィック分散

3.コンテナからPersistent Diskへ書き込み

4.ETL処理してデータ保存。ここまでこれから説明するうえでの簡単な前提

これらを踏まえて、李氏の体験をもとに「GKEバージョンアップで直面した問題と対策」を説明しました。

「GKEはマネージメントサービスであり、しかもKubernetesはバージョンアップ処理ができるので、僕自身、影響がないと思っていました。でも、実際にバージョンアップをしたときに、ローリングアップデートのバージョンアップの処理にも関わらず、ノードプールのアップデート時にログデータの欠損が発生しました。ログデータの1～２％程度の欠損が確認できました。GKEバージョンアップフローは以下の流れで行われます」

GKEバージョンアップフロー

1.バージョンアップ開始

2.新しいバージョンのノードとpodが追加される

3.古いバージョンのノードとノード上で稼働しているpodが切り離される

4.古いバージョンのノードを削除完了後、ノードの台数分だけ同じ動作を繰り返す

「rsyslogのサービス処理仕様は、通常のログ受信処理の仕様では、①ログデータを受信、②一時的にメモリ上にデータをキャッシュ、③メモリからデータを取り出し、④ストレージへ書き込む、という流れになります。先ほどのバージョンアップの処理と、rsyslogの動作を入れると、我々の中で推測したログの欠損ヵ所は、2ヵ所ありました。そこから以下の2つの仮説を立てました」

推測したログの欠損ヵ所からの仮説

1. オンプレ側にあるログ転送サーバからGKE Pod間の通信が不安定になる

2. GKE PodからPersistent Diskへのファイル書き込みが未完了の状態で終了してしまう

「そこで２つのテストを実施しました。1つはFirewall制御です。テストの結果、1回目はログ欠損率を0.01％以下まで下げることができましたが、2回目以降はログ転送サーバ側のrsyslogキュー処理が不安定になり、70～80％程度のデータ損失をする結果になりました。もう1つのテストは、コンテナのマニフェストを修正で、こちらは約0.1％までログ欠損を下げることができ、複数回実施しても同じ結果が得られました」

このことから、欠損原因はストレージへデータを書き込みする前にノードの切り離しが発生して、データをメモリに保持したままPodが削除されることで、それによりログが消失されてしまうことが確認できた、と李氏。

「リアルタイムで提供するGKEサービスの場合は、マニフェストチューニングによって最小限にすることができましたが、０％までできなかった原因についてGCPサポートに問い合わせたところ、GKEのアップデートをするときに、ノードプールで実行中のワークロードが中断される可能性があるので、マニフェストやファイアウォールでは仕様上、０％まで下げることができなかった、とのことでした」

最後に、これらのことを踏まえて、李氏は次のようにまとめました。 「クラウドのマネージドサービスを利用する場合、サービスの影響がないと思いがちですが、サービス内容によっては出る可能性があります。そのため、ミッションクリティカルなシステムを提供する場合は、サービス影響を調査することをお勧めします。弊社の実施した方法以外でも、バージョンアップ用のノードプールを追加、Istio導入によるトラフィック制御、GKE StandardからAutopilotへ移行検討などにより、影響をゼロにできる可能性があると思います」

■「世界最強のOSSコミッター企業・Alibaba Cloudはなぜデータに強いのか」

最後のスピーカーは、前職ではAzureのデータ分析領域のプリセールスを担当していたソフトバンク株式会社の藤井健志氏（資料作成は、同社の大原陽宣氏）。

まずは世界のクラウドサービスの状況について説明しました。

「世界には、Azure、AWS、GCPなど、さまざまなクラウドサービスがあります。クラウドサービス全体で見ると、中国はアメリカに次いで世界で2番目にサービスが使われている国です。Alibaba Cloudは中国発のサービスであり、中国のリージョンが格段に多いものの、ヨーロッパやアメリカも含め、西も東もリージョンを構えている、グローバルで使えるパブリッククラウドサービスです」

さらに、Alibaba CloudはAWS、Microsoftに次いで世界で第3位のシェアを誇り、アジア、中国では1位のクラウドサービスであることを強調しました。

「中国のGDPとAlibabaグループの成長を重ねたグラフを見ると、約10年前から中国のGDPが一気に伸びていくところにAlibabaグループのサービスもどんどん展開されていることがわかります。Alibabaグループがなぜビジネスに強い理由は、いろいろなサービスがまとまって1つの巨大なエコシステムになっている点と、常にデータを連携して活用している点です。購入履歴や支払い情報などを、AI、機械学習などを活用しつつ、グループ内で活用していくことで、少ないリソースで最大の価値をユーザに提供しているところにAlibabaグループの強み、特長があります」

毎年11月11日にAlibabaが実施している世界最大のショッピングイベント「独身の日」では、2020年は総売上が7.9兆円で、「日本のEC最大手の楽天さんの年間売上の2倍を、わずか数日で達成した」と説明。

「この独身の日の裏側で使われているのがAlibaba Cloudです。イベントがはじまり、日付が変わった直後に通信のピークが来ます。トランザクションは1秒間に最大58万件で、合計8億人以上の消費者が参加しました。それでもシステムを落とすことなく処理を完遂させました」

なぜAlibaba Cloudはそんなことができるのか？　藤井氏は、その原因の1つに“中国特有の事情”を挙げ、そもそも中国は人口が多い分、中国の各企業は日本やアメリカと比べて圧倒的にデータを大量に所有していて、さらにAlibaba Groupはデータ発生量が多いリテールやサービスの分野に力を入れていることが大きいと話します。 「技術的な部分でいうと、Alibaba Groupは過去にIBMやオラクルなど巨大なベンダを利用していたが、このデータ量から処理能力をはじめAlibaba Groupのビジネスが継続維持できないのです。そのため、Alibabaはベンダを脱却しながら、ベンダを超えたサービス・技術力が必要なので、オープンソースに力を入れはじめた経緯があります。 米中いろいろもめていたところ、オープンソースはアメリカの輸出規制を受けないという発表があり、中国政府、企業もどんどん使っていこうと積極的に投資を開始したんですね。結果、Alibabaは世界で3位のオープンソース貢献企業であり、GAFAや世界のどの企業よりOSSコミッターがたくさん集まっています」

Alibabaは技術だけで簡単にビジネスができること、そしてよりよい新しい未来を作ることを企業理念としています。それゆえに、Alibaba CloudはGAFAや世界各地の企業を支えるオープンソースを開発展開している著名なコミッターによる、この技術の集大成が、現在のAlibaba Cloudプロダクトサービスです、と藤井氏。

最後に、AWSなどの主要クラウドサービスとの違いを解説しました。

「AWSはアメリカの近代的で成熟した小売市場から培ったクラウドサービス。一方で、Alibaba Cloudは中国の脆弱な経済インフラ、未熟な小売市場から培ったクラウドサービスです。そのため、Alibaba Cloudは小売市場を生かしたさまざまなサービスを続々展開している。後発のサービスのため、費用対効果にも力を入れているため、非常に安い、というところもポイントです」

次回は？

第5回は、ソフトバンクの3人のエンジニアの方から、Azure、GCP、Alibaba Cloudについての話をうかがうことが出来ました。

最後に、司会の寺尾氏から次回についてアナウンスがあり、次回は、2022年1月13日(木)に、通常回とは異なり昼間の時間帯に規模を拡大して開催すると紹介がありました。

その名も、「SB Tech Festival 2022」。ソフトバンクが主催するもう一つのテックイベント Softbank DeepTech 2022 （翌日の1月14日(金)に開催）とも共同で開催するとのこと。