GMOペパボの3つの大きな変革期
常松伸哉氏：私からは「ペパボサービスインフラの今までとこれから」という題でお話しします。技術部シニアエンジニアリングリードの常松と申します。あだ名は「つねさま」ですが、最近「つねさん」と呼ばれることもあって、ちょっと寂しいです。
本日のテーマとアジェンダです。本日は、GMOペパボのサービスインフラの歴史を簡単に振り返って、GMOペパボのインフラの「過去」と「現在」と「未来」をお話できればなと思います。このあとも魅力的な発表が続くので、そこと一貫性のあるストーリーを作りながらお話できればと思っています。
「ペパボサービスのインフラの今まで」というところで、ちょっと歴史を振り返りたいと思います。GMOペパボには創業の2003年から3つの大きな変革点がありました。
1つ目は2015年で、2つ目が2017年です。いずれも「Nyah」と呼ばれているOpenStackによるプライベートクラウドですね。3つ目の2018年が「Nyah Kubernetes Engine」というNyah上で動くKubernetesクラスタ管理ツールのお話です。
NyahはGMOペパボで構築されているプライベートクラウドのコードネームでOpenStackで構築されています。各サービスのサーバー環境として利用されています。
2014年に構想が始まって、2015年に最初のバージョン、2017年に2つ目のバージョン、現在は2つ目のバージョンをアップグレードして運用している状態です。
オンプレミス運用からプライベートクラウド化した2015年
まず古いほうの「Nyah-classic」についてお話しします。
これはCTOのあんちぽ（@kentaro）が発表した「これからのペパボの技術」というスライドから抜粋しているんですが、オンプレミス運用から脱却して、より機動的な事業展開や、安定したサービス提供を可能にするためにインフラのクラウド化を目指そうと、プライベートクラウドに着手しました。
実際運用を開始して、狙った効果は得られました。一方で課題も多く残っていたので、今度はNyahの新しいバージョンを自前で構築・運用しようとなり、2015年に実際に取り組み始めました。
オンプレミス環境から脱却するためにOpenStackを使ったプライベートクラウドを導入し始めて、自社でもOpenStackの構築に取り組み始めたのが2015年のまとめです。
こちらは後ほどスライドを共有しますが、別で振り返ったスライドがあるので、詳しくはこちらを参照してください。
2017年に「Nyah-classic」と新しい「Nyah」を統合
2つ目が2017年に自前構築した新しいバージョンのNyahです。スライドは、新しいOpenStackのNyahと、古いNyah-classicの相互通信を検討していたときのスライドです。実際にネットワークで疎通がとれたので、徐々に新しいほうのNyahにマイグレーションしていきました。
副次的な効果としては、新しいOpenStackにすることで、インフラのコード管理ツールの「Terraform」によるインフラ管理ができるようになり、Infrastructure as Code（IaC）の促進になりました。
また、旧来は自分たちでロードバランサを作っていたのですが、「Octavia」というLoad Balancer as a Serviceを採用することで利便性が向上しました。
2017年のまとめです。2つのクラスタをネットワークで通信可能にして、並行運用しながらマイグレーションを行いました。副次的な効果として、TerraformによるIaCが促進されました。また、OctaviaによるLoad Balancer as a Serviceで利便性も向上しました。
私が「OpenStack Days Tokyo 2017」でお話ししたスライドがあるので、詳しくはこちらを見てください。
コンテナ化が避けて通れなくなった2018年
2018年です。課題の比較検討をしたときのスライドです。OpenStackを利用したNyahの運用では、サービスの新規立ち上げ時、もしくはインフラの追加時のリードタイムが問題になっていました。インフラ基盤に求められる要件が変わってきたため、現状のIaaSだけでは対応できないシーンが出てきたのが2018年です。
さらなる手立てが必要になり、コンテナを採用したいと考えていたのが2018年です。
2018年まとめです。プライベートクラウド化で確かにインフラ準備のリードタイムは下がりました。しかし、さらなる機動的な事業展開が求められている背景があったため、コンテナ化は避けては通れず、新しいチャレンジが必要になりました。
PaaS勉強会で今の検討について発表した資料があるので、詳しくはこちらを参照してください。
過去については以上です。
「minne」への導入に続き「Nyah Kubernetes Engine」の導入が進む
現在については2018年から現在になるのですが、Nyah Kubernetes Engineについてお話をします。
Nyah Kubernetes Engineは2018年より開発している内製のクラスタ管理ツールです。GMOペパボのNyah上で、Kubernetesクラスタを管理、構築、もしくはアップグレードという管理に特化させたツールです。
各種社内のセキュリティ基準があるんですが、それに準拠してクラスタを構築できて、共通のログ基盤にシステムのコンポーネントのログを集約できるクラスタを作れるツールです。ツールを利用して、サービスごとにNyah上にKubernetesクラスタを構築して、現在運用しています。
NKEの時系列ですが、2018年8月に実装を開始しました。2018年12月に「minne」のstagingクラスタを構築・導入。翌年の2019年4月に「minne」でKubernetesのクラスタを構築・導入して以降、各サービスへの導入が進んでいます。
簡単に利用状況をまとめました。現在GMOペパボのNyah上で動いているKubernetesクラスタ数は24個。利用しているサービス数はGMOペパボの商材で6つです。また、共用の「NKS」と言われているクラスタで1つ。「Wazuh」というセキュリティの統合管理ツールのクラスタで1つとで、計8サービスにまたがって24つのクラスタが展開されています。
現在のNyahのOpenStackバージョンは、Mitakaから導入されたものを1つバージョンアップして、Newtonにアップグレード済みです。引き続きin-placeでOpenStackバージョンへのアップグレードに取り組んでいきたいと思っています。
インフラに必要となる3つの要素
さて、ここまでGMOペパボサービスインフラの「過去」と「今」を説明しました。今後のGMOペパボサービスインフラの「これから」ついてお話ししたいと思うんですが、その前に「昨今の社会状況とその影響」について触れたいと思っています。
これは2020年4月に出したプレスリリースの内容ですが、弊社のECカートサービスである「カラーミーショップ」の2020年4月の前年同月比で、流通額が1.7倍、新規申込数が2倍に増加しました。
これは新型コロナウイルスを受けた新しい生活様式で、巣ごもり需要が増加して、弊社を含むWebサービスの重要性がますます向上していることを示唆していると考えています。また、今後もお客様が利用する機会はますます増加していくと予想されています。
それを受けて、今後インフラに必要となる要素を3つ考えてみました。「さらなる機動的な事業展開」「BCP（事業計画）観点での可用性の向上」「突発的なアクセス増に対する対策」が必要となる要素だと考えられます。一つひとつについて、内容とそれに対する対策について述べたいと思います。
「さらなる機動的な事業展開」ですが、いろいろな社会ニーズがある中で、エンジニアリングの集中をサービスの開発や安定したサービス運用に傾けていく必要があると書いています。
また、Digital X-formationとDeveloper Experienceの両方の頭文字を取ってDXと言いますが、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインである「DX Criteria」に沿った改善をGMOペパボでは進めていて、特にデータエンジニアリングに注力していきたいと考えています。
どういうことをしていくかですが、マネージドサービスの積極活用や、SREの取り組みや、データエンジニアリングそのものへの取り組みが必要だと考えています。
「BCP観点」では、現在物理インフラの所在が分散されているとは言い難い状況だと考えています。そのため、ロケーションレベルでの単一障害点の排除が必要だと考えています。これは現在使っているロケーション以外にも、複数拠点でのサービス運用が必要だということです。
最後に「突発的なアクセス増への対策」ですが、現状のオンプレミス環境では、設備増強のタイミング次第で突発的なアクセスに対応できないリスクがあります。ただ、常時ピークタイムを想定した備えになるとオーバーコストになってしまいます。アクセス増に対応しつつ、インフラコストも最適化しなければならないので、オンプレミス以外のマネージドサービスなどを積極的に活用する必要があると考えています。
今後注力していく3つのインフラ技術観点
以上を踏まえて、今後注力していくインフラ的技術観点をまとめました。この3つが今後注力していくインフラ技術観点です。1つ目はハイブリッドクラウド。2つ目はSite Reliability Engineeringの取り組み。3つ目がデータ基盤の整備です。それぞれ、現在行っていることとこれから取り組みたいことを説明します。
1つ目はハイブリッドクラウドです。これは複数ロケーションを使うということで、現在はAWSを利用していて、2020年に、NyahとAWSを「Direct Connect」（AWS DX）というサービスで専用ネットワークを接続しました。
実際にDirect Connectを使った構築について述べているスライドがあるので、後ほど参考にしてもらえればと思います。
実際にすでに行われている例として、「minne」を挙げました。もともと「minne」はAWSでサービス運用が始まっていましたが、途中でNyahとの併用に至りました。現在は、NyahのNKEでのKubernetesと、AWSのEKSの2つのクラスタで相互にサービスを提供することで、冗長性を確保しています。もともとVPNで接続していたのは、AWS DXの専用線を使うことでレイテンシが低下しました。
これがざっくりとしたサービスの運用概略図になるんですが、Route53で重み付けのロードバランシングをして、AWSとNyahのそれぞれにKubernetesのクラスタを準備することで、片方で障害が起きたときにもサービスを継続できる概略図です。
ハイブリッドクラウドを使ったケースのモデルケースとして、今後もGMOペパボではこういうサービス展開に取り組んでいきたいと考えています。
2つ目がSite Reliability Engineeringへの取り組みです。これはGoogleが提唱している運用方法についての理論なんですが、詳細は割愛します。
我々が在籍している技術部の責務は、昨今の社会事情を考えると、基盤インフラ整備だけではなくなってきていると考えています。特にサービス全体の安全性に責任を持つことが求められてきていると考えています。
そこで、Site Reliabilityの原理原則に則ってSREのプラクティスをきちんと実践していくことを目標にしています。例えばサービスやビジネスの可観測性を高めることでの可用性の向上や、ツール化・自動化を促進する中で、手作業による疲労の撲滅を目指しています。
SREのプラクティスである、SLI・SLO（Service Level Indicator・Service Level Objective）をもとにしたパフォーマンス改善の取り組みは、先日「ペパボテックブログ」に「ロリポップ！」の例を載せたので、ぜひ見てもらえればと思います。
最後にデータ基盤の整備ですが、ビジネスにおけるいろいろな意思決定のもととなるデータの重要性の増加もあるので、サービスの安定稼働によるインフラのメトリクスやキャパシティプランニングに必要なデータの収集・分析・活用が、「事業KPI」「サービスの安定稼働」の双方に求められていると考えています。
我々は、インフラ基盤のターゲットはデータ分析基盤へも広がっていると考えていて、GMOペパボのログ活用基盤である「Bigfoot」のデータ活用基盤の整備とインフラ、GMOペパボの各サービスとの連携を進めていきたいと考えています。
2021年1月にデータ基盤チームを設立して、データパイプラインの整備やダッシュボードの整備によるデータ可視化に現在取り組んでいます。今後も注力していきたいと考えているところです。
まとめです。本日のスライドではGMOペパボのサービスインフラの歴史を簡単に振り返りました。オンプレミス期、Infrastructure as a Service期、Container as a Service期と徐々に変革していると考えています。現在はGMOペパボNKEで取り組んでいるKubernetesクラスタを運用しているCaaS期です。
今後やりたいことで、ハイブリッドクラウド、SRE、データ駆動を紹介しました。我々技術部は、インフラだけでなくデータ基盤の整備もやっていきます。
最後ですが、本日のプログラムでは各チームでのそれぞれの取り組みが実際にどうなっているかが説明されるので、以降の発表も引き続きお楽しみにしてもらえればと思います。
私の発表は以上です。ありがとうございました。
