内定者アルバイトから新卒として入社した2023年の振り返り

サムネイル

内定者アルバイト時代のプラットフォーム事業本部第3開発部不正対策チームでの経験（「Hedged Request」機能追加）
セキュリティ部に配属されてからの経験（セキュリティをやる意味）
最後に
宣伝

ITインフラ本部セキュリティ部サイバーセキュリティグループに所属している23新卒の萩原です。

この記事では、1年の振り返りとして内定者アルバイト時代にプラットフォーム事業本部第3開発部不正対策チームで作った「Hedged Request」機能と、学生時代にセキュリティを専門的に学んでいた私がDMMのセキュリティ部に所属してからさらにセキュリティについて考えた結果、私が今考える「セキュリティをやる意味」についても書いていこうと思います。

内定者アルバイト時代のプラットフォーム事業本部第3開発部不正対策チームでの経験（「Hedged Request」機能追加）

Hedged Requestとは何か

「Hedged」は、金融用語の「（リスクを回避・分散する上での）両賭け」に関連していると思っています。詳しくはこちらの記事をお読みください。

「Hedged Request」で行うことは、リクエストのレプリカを複数生成して一番早い応答を採用することで、遅延のバラツキを抑えることでスループットを向上させることを目的としています。

メリットと結果

一発目のリクエストが何かしらの影響で遅い場合、複製したレプリカの中で一番早いリクエストを採用することで処理速度を高速化する
遅いリクエストが飛んできた場合、タイムアウトさせるのではなく再送させることで処理ができる（ユーザー視点で見るとログインできないことが減る、開発者視点では可用性が上がる）
99%タイルでのレイテンシが大幅に上がる（あるAPIに導入したところ従来の1/3から1/2までレイテンシが下がりました)

しかし、この機能単体ではレプリカを複製するため大量にアクセスを受け取り、逆にレイテンシが悪化するというリスクが存在するためにトークンバケットの考え方を用いたレートリミット機能を追加で実装する必要があります。今回、そこの実装もしたので併せて紹介していきます。

トークンバケット

トークンバケットは、バケット内のトークンの存在に基づいてトラフィックの転送をいつ行うかを指示する制御機構です。バケットには複数のトークンがあり、それぞれがあるバイト列単位に対応したり、事前に設定した大きさの1つのパケットに対応しています。バケット内のトークンはパケットを送信する際に削除されます。トークンは1秒おきに追加されるという機能です。

今回、Hedged Requestで使用したトークンバケットはバケットの中に１秒間に送られてくるレスポンス総数の10%のトークンを入れておき、packetをトークンの数まで送ってそれをオーバーしているものに関しては破棄するというものです。

この機能のメリットとして、以下が考えられます。

ある程度バースト性（あまりに時間がかかるようなリクエスト）のあるパケットに対して対応できる
外部要因でのシステムへの負担を減らせる（通信先の回線等が壊れていてリクエストの処理に時間が掛かるまたはシステムそのものを落としてしまうような巨大なリクエストを破棄できる）
システムへの負担を制限できる

苦労した点・もう少し頑張りたかった点

あまりにも参考文献が少なすぎて実装するために必要な情報が少なかった
そもそもhedged自体の記事が少ないためといったことや要件的な問題でレートリミット機能をgoライブラリにある関数などを使わないで実装したため、もはや未開の地を開拓するようなことをやってしまい、コードをレビューしてもらおうにもレビューする人が苦労する、何をやっているか分からないからレビューできないという事態に陥ってしまった（そのため他チームの持っている負荷試験基盤を借りて負荷試験をしてから実装するという手順を踏みました）
そもそもhedgedを実装した段階でリクエスト数が増えるため、レートリミットでリクエスト数を減らしてもhedged自体がリクエストを不必要に実行してしまうという脆弱な側面があり、レイテンシを下げることはできたとしても限られた場面になってしまうため、これらを解消するためにはさらにtied requestを実装してリクエストが処理された時点で残りの受け取ったリクエストを破棄するようにしながら、他の場面でも使えるようにして、さらにレイテンシを下げたかった（自分の引越しの関係で内定者アルバイトを辞めなくてはならなかったので……）

セキュリティ部に配属されてからの経験（セキュリティをやる意味）

なぜセキュリティをやるのか

周りからのセキュリティに対するイメージでは「セキュリティ範囲をどこまで行えばいいかの判断が難しく、また分からないこともあり、いざ仮にこのあたりまでセキュリティ対策を行うとなってもかなり面倒！（後回し）」という方も多いかと思います。しかし、これはビジネスをやっていく上では非常に重要な問題です。ビジネスにおいては信用問題がかなり関わってくるため、仮にセキュリティを適当にやってしまうと信用がガタ落ちになり、会社の利益が下がるなどといった問題が起こり、会社が傾きかねない問題に直面する可能性が非常に高くなります。
そういった問題を減らしていくためにもセキュリティはやっていくものだと私は考えています。

また余談ですが、実際にセキュリティ対策をしていく上では定性分析から定量分析をして、ALE（年間予想損失額）を組み込んだTCO（総コスト）を出した上で、セキュリティ対策に対して予算を出してもらいます。このことから実際にどこまでのレベルをやっていくかもある程度は絞ってあり、リスクを回避しないといけないものは回避するように会社レベルで動いています。
「面倒！」だからといって後回しや放置は非常に良くありません。

実際にセキュリティを適当にやっているとどうなるのか

世間一般でのセキュリティニュースの代表例をいくつか挙げます。

「機密情報を入れているストレージ（Googleドライブみたいなもの）が社外の人がアクセスできるようになっていて情報が盗まれました」
「サーバに誰でもアクセスできるようになっていて知らないうちに意味不明なプログラムやソフトが動いてました」
「自分の誕生日などをパスワードに設定してて総当たり攻撃でID乗っ取られました」

セキュリティを適当に行うと、このようなことが起きやすい状況になります。
そうなると個人情報やクレジットカード情報が漏れた場合、ユーザーとの信頼関係が崩れたり、賠償請求が来たり、AWSなどのクラウド上で事故が起これば最悪クラウド事業者から契約が打ち切られるといった困った事態を招きます。

どこの会社・団体とはあえてここでは言いませんが、適当な情報管理下で個人情報を預けるなど怖すぎて不安しかありません。（実際にニュースになっていたり、いろんな人から反発が起こったりと一般企業であれば倒産も）

上記を踏まえて今考えていること

しかし、私は過去にバックエンドをメインにやっていたこともあり、現場の開発者にとって「セキュリティは面倒くさい」という見方もわかります。また、ただでさえ納期などがあるので「優先的に開発に時間を割きたい」という方が多くなるのも仕方がないことだとも思います。
その点を踏まえて「いかに開発者側へ負担をかけないようにしてセキュリティ対策を考え、実行に移すか」というところが一番重要な点だと私は思っています。これからまた新たにセキュリティシステムや対策を考えていくときにはどのようにしたら開発者がセキュリティ対策に協力してもらえるのかを、最近考えながら対策を練っているところです。

最後に

内定者アルバイトでの開発の経験や入社してからさまざまなことを学んだ１年間でしたが、それ以上に技術に対して面白いと思える環境に出会えたことにとても感謝しています。実際にセキュリティ部や内定者アルバイトでいたチームもそうですが、DMMに入社してから面白い人たちや独特な感性を持った人に多く出会い、以前よりもいろいろな面で楽しいと感じられているため、入社して良かったと思っています。

私は今後さらに経験を積んで周りのモチベーションを上げられるような人物になりたいと思っています。

ー参考文献

https://spring-mt.hatenablog.com/entry/2021/05/18/165241
https://qiita.com/tfutada/items/750740d7d5977b1d72b8
https://pkg.go.dev/golang.org/x/time/rate
https://medium.com/swlh/hedged-requests-tackling-tail-latency-9cea0a05f577