GMO Developers Day 2022｜クラウドネイティブセッション / 開発者向けブログ・イベント

GMOインターネットグループでは、2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day 2022」を開催しました。

「GMO Developers Day」は、GMOインターネットグループの最新技術を活用した新しい挑戦や、世の中が抱える課題解決への取り組みを、事例を交えて紹介するテック（技術）カンファレンスです。開催3回目となる今年は「Add on 技術の拡張で、新たな世界へ」をコンセプトに、初のオフラインとオンラインのハイブリッド開催で、全34セッションをお届けしました。

GMO Developersではそんな大盛況を収めた同イベントのセッションを紹介していきます。今回は2日目にリアル会場で開催された「クラウドネイティブセッション」をご紹介します。

登壇者

スピーカー

山下和彦
GMOペパボ株式会社
技術部技術基盤チーム
佐藤慎治
GMOグローバルサイン・ホールディングス株式会社
マネージドサービス事業推進室
山崎牧彦
GMOペイメントゲートウェイ株式会社
ITサービス統括部オペレーション・セキュリティ部サービス運用

モデレーター

長谷川泰斗
GMOインターネットグループ株式会社
インフラ・運用本部クラウドサービス開発部コンピュートプロダクトチーム

（左から）GMOインターネットグループ長谷川、GMOペパボ山下、GMOグローバルサイン・ホールディングス佐藤、GMOペイメントゲートウェイ山崎

クラウド移行で、気になる「従量課金」

GMOインターネットグループのエンジニア4人が集まったセッション。クラウドだけでなく、オンプレミスのサービスにも精通している4人が、自社のサービスで利用するサーバーやアプリケーションなどについて語り尽くしました。

最初にモデレーターの長谷川が問いかけたのは、「従量課金の計算」について。オンプレミスからクラウドに移行した場合、従量課金で毎月の料金がどの程度変わるのか、という点を尋ねました。

GMOペイメントゲートウェイでは、AWS（Amazon Web Services）を採用していて、請求単位のAWSアカウントがサービスごと、環境ごとで分かれていていると山崎は説明。サービスごとに稟議を出して、それを元に予算が決まっていると話します。「円安で予算の計算が狂わなかったか」と問われ、山崎は「計算は狂っていませんが、それでも円安は大変で、コスト削減策も考えています」とのこと。

コストに関しては、AWSの機械学習を用いたコストの異常検知アラーム設定を活用。特定のアカウントで急にコストが上がれば通知するという設定にしているといいます。

急激なコスト増だけでなく、「AWSでよくあるのが、ちょっとした作業でインスタンスを起こした際に、後で終了させるのを忘れてしまうこと」と話したのが山下。こうなってしまうと、ずっとコストがかかり続けてしまいます。

こうした状況に対して山崎は「定期的に棚卸しをする」という対策を示しますが、それでもアカウントの数が多いことで、担当者によっては放置されてしまうこともあり、注意が必要と話します。そのため、インスタンスの監視運用のためにLamdaを使って、「定時内しか起動しない」などの設定を実施しています。

佐藤は、「同社がB2B向けの運用サービスを提供しており、コストの請求ツール提供、コストの監視設定、サーバーのトラフィック、サーバーのパフォーマンスといった監視も可能です」としています。ただ、それでも全てを完全にチェックすることは不可能で、コストなどに大きな変化があった場合に「SNSやSlackに送る」という使い方を紹介します。

どのようにナレッジの共有を行っているか

続いての質問では、長谷川がVM（仮想マシン）からコンテナ、オンプレミスからコンテナといったように、クラウドへの移行に際してのナレッジ共有をどうしているのか、と問いかけました。

GMOペパボは、山下が入社してすぐの7年前頃にはプライベートクラウドのOpenStackでサーバー基盤を開発していましたが、現在はコンテナに移行していると説明しました。OpenStackは、GMOインターネットグループのConoHaで使われており、そのナレッジがあったのでそれを活用して構築したものです。

当初はサーバもレンタル契約でConoHaのOpenStackのノウハウをそのまま持ち込んでいたのですが、その後はサーバも自社で調達し、OpenStackのバージョンアップをしたほか、Kubernetesへも移行して、社内でコンテナ技術に関する知見を深めていきました。同社のサービスである「ロリポップ！マネージドクラウド」でコンテナ中心のサービスを提供したことでも知見を深められたといいます。こうして自分たちでナレッジを積み上げたのがGMOペパボです。

ちなみに、GMOペパボは事業部制で、「ハンドメイドサービスのminneでは9割がKubernetesで、AWSとオンプレミスのハイブリッドクラウド」（山下）でサービスを運営しています。。通常はOpenStackで9割のトラフィックを処理していますが、ピーク時にはAWSとオンプレミスの比率を変えることで処理を行っています。当初は手動で比率を変えていましたが、現在はトラフィックに応じて自動で比率を変えるようにしているそうです。

「AWSは移行のためのツールが揃っている」と話すのは佐藤です。「オンプレミスからAWS、クラウドからAWSへの移行など、マイグレーションツールを使うことでどの環境でも移行に対応できるようナレッジを蓄積してきました」と言います。それでも対応できない古いサーバーであれば、どのように対応するかは「お客様に合わせてお手伝いする。結構需要があります」（佐藤）とのこと。

他にも、「マルチクラウドの案件が増えてきている」（佐藤）。Googleの良さ、AWSの良さ、オンプレミスの良さはそれぞれあり、「いいとこ取りをしようと考えています」と佐藤は話します。

クラウド利用時のセキュリティについて

次の「クラウド利用時のセキュリティの留意点」という質問には、まず山崎が「AWS Security Hubを使って、なるべく簡潔に運用コストを減らしています」と回答しました。Security Hubで検出された項目に対して、AWSアカウントの担当者に通知して修正してもらい、修正をチェックする、という手順になっているといいます。

GMOグローバルサイン・ホールディングス社のCloudCREWでは、お客様に提供するサービスとしてAWS Security Hubにも対応できるほか、お客様がセキュリティに興味がある、セキュリティを重視しているといった場合には、それ以外のセキュリティサービスも提供できるようにしています。AWSには複数のセキュリティに関するサービスがあるため、お客様にどのようにそのサービスを分かりやすく伝えるか、といった点を考えた結果、「新しいセキュリティサービスの設計をしているので期待して下さい」（佐藤）。

ただ、Security Hubは通知が多いため「ノイジーなところがある」と山下は指摘しました。GMOグローバルサインではSecurity Hubそのままの情報を提供するのではなく、精査をして重要なものだけを通知するようにしていると佐藤は説明。「クリティカルなものを通知するのが一番いい」というのが佐藤の判断です。

山崎もフィルターを設定しており、セキュリティ担当者と精査していると話します。Security Hub上では重要度が低い表示になっていても、環境によってはリスクが高い場合もあるとして、工夫が必要という認識を山崎は示します。

どのようにログを収集して、活用しているか

続いての議題はログ収集について。長谷川は、「Kubernetesでコンテナを立てていますが、コンテナがなくなるとログも消えてしまいます。どう収集していますか？」と問いかけます。

山下は、ライフサイクルによって変更しているとのことで、「基本的にはコンテナのログを集めて、それをApache Kafkaに出力。さらにそこからAmazon S3に保全する、BigQueryを使って解析に利用する」といった使い方をしているそうです。保存期間が短いログであれば、Grafana Lokiも使っていて、ログの検索もできるようになっているとのこと。

Grafana LokiはURLを使ってログの共有ができる点が便利だと山下。ライフサイクルに関しては、例えばセキュリティ関連のログは3～5年の期間、Amazon S3に保管していると話します。

GMOペイメントゲートウェイでは、オンプレミスのサービスではログ集約サーバーがあるのでそこに保管。AWSを使っているサービスでは、最終的にAmazon S3に集約して、ライフサイクルに応じて処理していると山崎は説明します。同社では、AWSアカウントごとに担当者がおり、それぞれログを調査したいといった場合もあるため、Amazon S3のバケットなどで調査分析をできるようにしているといいます。「集約を忘れないことが重要です」と山崎。

佐藤は、「ログは事件が起きたときに引っ張り出すのが重要」と指摘。「Amazon S3に蓄積して、BigQueryを使って見やすい状態にできるので、クラウドネイティブのサービスでもオンプレミスでも、ログだけは一貫した使い方をします」と説明します。

「実際の事件とまでは行かなくても、ヒヤリハットな事例はありましたか？」と長谷川が問いかけると、山下が「OpenStackのポートの論理情報を全て消してしまったことがありました」と明かしました。OpenStackは構成情報をキャッシュのように保持していて、マスターを消去してしまってもキャッシュが動作している限りは復元できるため、データベースを復旧して事なきを得たそうです。

山崎は、Amazon GuardDutyを設定しておいて良かったと感じているそう。「マネージド型脅威検出サービス」として活用されるGuardDutyですが、これまで一度だけアラートがあり、AWSの権限の設定間違いが検出されていたといいます。これ自体は大きな問題となるものではなかったのですが、通知によって問題に気付くことができたとその効果を指摘。「イベントベースでアラートを発行してくれるというのは、オンプレミスだとなかなか難しいのではと思っていて、それがクラウドの良さだと思う」と山崎は話します。

こうしたセキュリティ系のサービスは「よく分からないことをしているだけで料金が取られる、と感じてオフにしてしまう人もいる」と山崎は注意喚起をして、「地味な足回りですがセキュリティをきちんとやっていくのは大事」と強調します。

セキュリティ面では、スピーカーの山下が他の面々に対して質問もしていました。プログラミング言語のパッケージやコンテナなどの脆弱性の管理をどうしているか、というものでした。

佐藤は、お客様次第としつつ「IPアドレスで制限して入ってこられないようにしてしまう」という方法を紹介。「脆弱性は即時に対応できるものばかりではないので、対応が遅れたら危険なクリティカルなものを選んで対処している。どうしても対応できないものに対しては、アクセスをなるべく遮断しておくことで対応しています」と話します。

山崎は、社内のセキュリティ組織が脆弱性情報を集めて対策を検討し、対応が必要ならば通知が来るようになっていると説明します。AWSのコンテナでもオンプレミス上のアプリでも、どういったものが動作しているかインベントリーを収集して、脆弱性が関連するかどうかを見極めているそうですが、山崎は「まだ完全ではありません」と話します。

GMOペパボも同様の仕組みで対処をしていると山下は説明。危険な脆弱性であれば即日対処するといったように、危険度に応じた対処が重要だという指摘には佐藤も同意していました。

クラウドネイティブと、どう向き合っていくか

最後にコメントを求められた佐藤は、「クラウドネイティブの今後をどう捉えていくか」という質問を投げかけます。これに対して山下は「ひとつのキーワードは可搬性」と言います。これは、AWSでもGoogle Cloudでもどのクラウドでも、そしてKubernetesでもCloud FunctionsでもLambdaでも動作する、といった具合に1バイナリで環境を問わずに動作する世界を想定していました。

山下は、「Wasm（WebAssembly）が流行しかけているが、もうちょっと色んな言語で速く動くようになると、そんな時代になるのではないか」と期待感を表明。WasmがWebアプリケーションでもいろいろなプラットフォームで使われるようになると「アーキテクチャが変わってくるかもしれない」との考えを示します。

山崎はAWSが「一昔前はインフラを提供しているイメージだった」としつつ、例えばシムシティのような大規模3Dシミュレーション演算ができるサービスも提供するなど、幅広い領域に進出していると言及。結果として、AWSやGoogle Cloudなどはインフラエンジニアだけが触れるものだと避けるのではなく、アプリケーションエンジニアもどのように活用するかを考える必要性を指摘します。

こうしたコメントを受けて、長谷川自身もオンプレミスでのKubernetes構築の中で、OSやきょう体によって動作が異なるという点に苦しめられてきた経験を話し、基盤に関係なくアプリケーションがどの環境でも動作するのは重要だと同意していました。