大規模サービスを展開する国内ITベンダー6社による「6社合同SRE勉強会」が2022年3月12日に開催された。ディー・エヌ・エー(以後、DeNA)は「Public CloudのさまざまなDeNA的管理手法」と題し、ほとんどのサービスをパブリッククラウド上で運用している同社における「コスト管理」と「セキュリティ管理」のための取り組みを紹介した。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
LINE、メルカリ、クックパッド、DeNA、サイバーエージェント、リクルートの6社は、2022年3月12日に「6社合同SRE勉強会」をオンラインで開催した。同勉強会では、各社でサービス運用に関わるエンジニアが、自社でのSRE(サイト信頼性エンジニアリング)に関連した取り組みを紹介すると同時に、他の企業のエンジニアとの質疑応答を通じて知見が共有された。
DeNAからは、システム本部 IT統括部 IT基盤部 部長の鳥越 昇氏と、IT基盤部 ネットワークグループの尾留川 良太氏が登壇。鳥越氏は主に「コスト管理」、尾留川氏は「セキュリティ管理」の観点から、同社がパブリッククラウド上でのサービス展開に当たって実施している管理手法の一部を紹介した。
鳥越氏は、DeNAの創業期からIT基盤部に所属。以来、一貫してIT基盤部で、全社共通基盤の運用と同社の主力事業を支えるITサービスの運用およびSREの活動をしている。
「DeNAのイメージはモバゲーを中心とした『ゲーム』、野球チーム運営の『スポーツ』が強いと思われるが、それ以外にも、近年好調なライブコミュニケーションサービス『Pococha』やヘルスケア、カーシェアリングなど、幅広くさまざまなITサービスを展開している。現在、これらのサービスのほとんどが、パブリッククラウドを活用して運用されている」(鳥越氏)
オンプレミスで運用していたサービス基盤のパブリッククラウド移行は、2018年にスタート。以来、2021年4月までの約3年をかけて、ほとんどのサービスの移行を完了した。移行に当たっては、IT基盤部を中心とする「パブリッククラウド管理チーム」が組織され、クラウドの利用、管理に関わるスキームやルールの標準化を進めた。
現在も、パブリッククラウドのアカウント数は日々増加している。「Amazon Web Services(AWS)」と「Google Cloud Platform(GCP)」を中心に利用しており、2022年3月時点でAWSのアカウント数は290超、GCPのプロジェクト(アカウント)数は800超だという。
「パブリッククラウドを大規模に運用する上では『コスト監視と管理』『アカウントの権限管理』『アカウントそのものの管理』『セキュリティ管理』など、さまざまな観点での運用最適化が必須だ」(鳥越氏)
同社におけるGCP上でのコスト管理は、全てのプロジェクトに対して週次で課金額を集計し、定められたしきい値を超えた場合に、そのプロジェクトの管理担当者に対して自動的にメールアラートを発する仕組みを構築している。
アラートのルールは、1プロジェクト当たりの課金が「月100万円を超過した場合」あるいは「月80万円を超過し、かつ前月比で150%以上増加している場合」というものだ。この標準ルールに基づくアラートが適切でない場合には、個別の依頼ベースでルールを設定しているという。
課金情報は、GCPの「Billing Export」を利用して、定期的にGoogle Cloudが提供する「BigQuery」に出力する。集計および結果に対する処理は「Google App Engine」のフレキシブル環境上で定期的にスクリプトを実行し、ルールに抵触するプロジェクトを検知した場合には外部のメール配信サービス「Mailgun」を利用して、担当者にアラートメールを送信するという流れだ。
「課金単位となるアカウントがひも付けされたプロジェクトによって、課金データが自動的にエクスポートされるため、プロジェクトの追加や削除に伴う対応が不要になる点で手軽だといえる。BigQuery上で管理される課金データはプロジェクトごとにデータ閲覧権限を厳格化し、該当プロジェクトのコストデータは、プロジェクトを担当しているメンバーだけが閲覧できるようにしている」(鳥越氏)
各プロジェクトにおけるコストデータの可視化には、BigQueryと「Google Data Studio」を組み合わせて活用しているという。「サンプルのレポートが用意されているので、それを利用して簡単にダッシュボードが作成できた」(鳥越氏)。なお、この内容はGCP上で運用されているサービスであることが前提だが、AWS上のアカウントに対しても、課金データの収集手順が異なるだけで、基本的には同じ仕組みでコスト管理、監視、可視化を実施しているという。
「この管理手法を導入して以来、担当者が意図しなかったコスト増を複数回発見できており、コスト管理に貢献できたと感じている。今後はアラートを出すしきい値に、より柔軟性を持たせた上で自動的に設定される仕組みも検討したい。利用状況が不規則なサービスはコスト変動が大きくなりがちで、現状のルールベースで一律に出すアラートではノイズになるケースもある。別途、予算や売り上げなどのデータと組み合わせた分析で、より適切にアラートを出せる仕組みを考えたい。加えて、現在は週次で集計している頻度を上げ、よりリアルタイムに近い形で監視できるようにしたい。BigQuery上のミスクエリでループが発生した場合、最悪、数百万単位の浪費につながる可能性もある。そうした状況が起きないような監視体制を検討していきたい」(鳥越氏)
後半は「セキュリティ管理」における取り組みを、尾留川氏が説明した。
パブリッククラウド上で多数のサービスを運用する際には、それぞれの環境に応じた脆弱(ぜいじゃく)性対応、運用しているIPアドレスの管理など、さまざまなセキュリティ対策が必要になる。尾留川氏は対策の一例として「SSHポート」の管理を挙げた。
「環境構築時のオペレーションミスなどで、サービスのSSHポートがインターネットに開放されてしまうケースは非常に起こりやすく、これが大きなセキュリティリスクになる。DeNAでは、全社標準の対応として、定期的にSSHポートの開放検知を実施している」(尾留川氏)
SSHポートの開放検知は「外形監視」の手法で行われている。まず、社内のリソース(インスタンスやロードバランサー)が利用している全てのグローバルIPアドレスを収集。収集されたアドレスに対してSSHを試行し、もしレスポンスがあれば、そのアドレスを利用しているプロジェクトの担当者に通知するという流れだ。
尾留川氏はこの手法の利点として「パブリッククラウドを横断した全環境の監視が可能」であることと「オートスケーリングなどによる頻繁なIPアドレスの変更にも対応可能」である点を挙げた。一方で、弱点としては「監視対象が大量なため、検知までに一定の時間(現状、全体で約15分)がかかる」「検知から通知までは自動だが、SSHポートの設定変更はユーザーによる手作業になるため、短時間で対応されるとは限らない」ことを指摘した。
同社では、特に「手動での設定変更による対応までのタイムラグ」という課題を解決するため、AWS上で運用されるアカウント向けに「自動修復」の仕組みを構築しているという。
自動修復の仕組みはこうだ。各AWSアカウントのセキュリティグループを監視し、その中に「SSHポートを開放する」ルールが検知された場合に、自動的にそのルールを削除する。セキュリティルールの変更は「AWS Config」によって検知し、「EventBridge」を介してイベントを集約。SSHポートの開放を認めるルールの削除は「AWS Lambda」から実行するという構成だ。
だが、この構成の場合、事情によって意図的にSSHポートを開放している「例外」のケースに対応できない。そのため、同社では例外対応のための仕組みも合わせて作り込んでいる。これは、内製のアカウント台帳アプリと、例外条件をまとめたスプレッドシード上のデータを組み合わせて、Lambdaによる自動的なルール削除から除外するというもの。例外条件のスプレッドシートには「アカウント名」「除外するセキュリティグループのID」「除外期限(日時)」が登録されており、除外期限を過ぎた場合には、自動的にルール削除の対象となる。
この自動修復の仕組みにより、AWS上で運用しているサービスは、SSHポートの開放検知から、ルール変更による修復までを、例外対応も考慮しつつ非常に迅速に実施できるようになっているという。ただ、AWS以外のパブリッククラウド環境には対応していないため、マルチクラウドでの対応が今後の検討課題だとしている。
「6社合同SRE勉強会」では、各担当者の発表後に「Ask the Speaker」として、発表者と他企業のSRE担当者による対談の時間が設けられた。発表中に視聴者から寄せられた質問に対する回答なども、この時間で行われた。同セッションでは、クックパッドでSREグループに所属するmozamimy氏が、Ask the Speakerを担当した。
mozamimy氏は、コスト管理に関する鳥越氏の発表で「BigQueryデータの閲覧権限の厳格化を実施している」と紹介した内容に言及し「クックパッドの場合、各プロジェクトのコスト状況を、特に制限なく全体で共有できるようになっている。権限の厳格化が必要な背景を聞きたい」と質問した。鳥越氏は「DeNAの場合、事業領域が非常に広いこともあり、社内であっても、コードネームすら秘匿されるような案件が動いているケースがある。そのため、権限管理も厳格に行っておく必要がある」とした。コストの可視化に当たっては、企業それぞれの文化やニーズといった事情に応じて、権限管理スキームの設計をする必要がありそうだ。
聴講者からの「スプレッドシートでの例外条件管理では、オペレーションミスなどによるデータ破損リスクに対策をとっているか」という質問に対し、尾留川氏は「現状では人手によるチェックを行っている。用途と利用頻度を考えた場合、各ユーザーが簡単に例外を追加できる仕組みとして、最もシンプルな方法がスプレッドシートだった。今後の運用状況次第では、アプリ化も検討の余地があると考えている」
Copyright © ITmedia, Inc. All Rights Reserved.