インターンシップとしてエキサイトブログのバックエンドに関わった話

こんにちは！エキサイト株式会社にて、8月の就業型インターンシップ Booost!!! Excite Internship 2024に参加させて頂いたketakataと申します。この記事では、インターンシップに参加した理由と、参加を通して得られたことを中心に書いていきます。

自己紹介
私が関わったプロダクト
インターンの進め方
開発から得た学び
- 高トラフィックに耐える設計
- 確実に正しく動く設計
最後に

自己紹介

普段は大学院で修士1年として、情報科学を専攻しています。研究ではRegoという言語で書かれたコードの可視化ツールを、React/Goで開発しています。普段の開発でも、Web技術を用いて、自分や周りの人がほしいと思ったソフトウェアを書くことが多いです。一方で技術系のアルバイトやインターンの経験はまったくなく、そろそろエンジニアの一員として働く経験を積んでみたいと思うようになりました。いろんな分野に触れてみたいという思いはありつつも、まずは一番興味のあるバックエンド志望としてインターンを探すことにしました。

そのような中、エキサイト株式会社メディア事業部のバックエンドに、インターンとして携わらせていただくことになりました。初の実務経験でしたが、恵まれた環境の中で非常に多くの学びを得ることができました。

私が関わったプロダクト

エキサイトには様々な事業があります。その中でも私はメディア事業部の「エキサイトブログ」というサービスの開発に関わりました。インターン生として関わったタスクは、主に以下の2つになります。

エキサイトブログ20周年に向けた、無料ユーザーへの有料記事開放（制限付き）のための機能改修
エキサイトブログ管理のために行っている作業の一部自動化バッチの作成

期間が限られていることもあり、タスクの大枠はある程度用意されていましたが、詳しい要件定義や実装の方針などはかなり任されている印象でした。任されているとはいえ責任が重すぎることはなく、コードレビューも非常に丁寧に行われているため、大きな変更でも行いやすいと今までの開発と比べて感じました。

インターンの進め方

私が実務インターンを探していた理由の一つとして、「普段のエンジニアの業務がどんな感じなのか、自身で体験してみたい」という思いがありました。結果としては、かなり解像度の高い体験を得ることができました。というのも、環境構築が終わって以降は、かなり自由にタスクを進めさせていただいたからです。実際に、各日の業務の流れはこのような感じです。

10:00 出勤（貸与されるMacを使ったフルリモート）
10:00~ 朝会
- 進捗や相談事をチームで共有します
- 皆が着実に自分のタスクを進めていて、いい刺激になります
- 皆さん褒め上手なのでモチベが上がります
~18:30 各自の業務
- 随時、MTGや勉強会、休憩など
18:30 業務終了

他の方を見ていても特に印象的だったのは、チームのメンバーがお互いを信頼し合っていて、困ったら気軽にTandemなどで聞ける環境であったことです。

私もインターン期間中、些細な質問など多くさせていただきましたが、毎回1聞いたら10返って来るので、毎回非常に勉強になっていました。それはプロダクトの質を保つためだけではなく、チームの一員としてこちらの成長も考えてくれているからだと感じました。特に、「今までそうやって開発してきたから」だけに留まることなく、そうすべき背景も含めて話してくださったのがとてもありがたかったです。

私の就業環境としてはフルリモートであったため、そのような環境でも気軽にヘルプを出せるかどうか心配な部分もあったのですが、こちらが緊張している中メンターの方から積極的にコミュニケーションを取ってくださったこともあり、結果としては杞憂に終わりました。

マイクロマネジメントがない分、普段の時間の使い方にも自主性が強く求められると感じました。特に私の場合、日中ずっとひとつのプロダクトを開発するということはこれまでに無かったので、タスクの進め方で迷子になってしまうこともありました。その対処として、個人的に特にうまく行った取り組みがポモドーロ・テクニックです。これによってかなり集中力を保つことができたと感じています。業務中ずっと監視されているということもないため、こういった手法を取りやすい環境も魅力的に感じました。

開発から得た学び

エキサイトブログはPVが非常に多く、また様々な機能を備えているサービスです。そのようなサービスの開発に関わることには、大きな責任が伴います。私が行ったタスクそのものは大きなものではないのですが、実際に実装に取り掛かってみると、予想外に気をつけるべきことが多いことに気付かされました。その例を２つに絞って挙げます。

高トラフィックに耐える設計

前述の通り、エキサイトブログには毎日たくさんのアクセスがやってきます。その数は事前に予測がつくものではなく、次の日にトラフィックが多くなるか減るかは誰にも予測がつきません。もし平均トラフィックぎりぎり想定でサーバー台数を用意していたとしたら、簡単にアクセス過多を起こしてブログがなかなか読み込まれなかったりするでしょう。

幸いにも、エキサイトブログでも利用しているAWSでは、オートスケールという機能によりこのような事態を防ぐことができます。サーバーインスタンスの数を現在のトラフィック量に応じて自動で増やしたり減らしたりしてくれるので、今ではこのような問題はあまり見られなくなりました。

しかし別の問題があります。従量制課金とはいえ、AWSにもお金がかかります。実際にAWSの課金額を見せていただいたのですが、その中でもRDS（データベース）は大きな割合を占めています。

特にこのデータベースの課金額、つまりアクセス負荷は、大元のトラフィック量だけでなくバックエンドの実装・SQLの書き方次第でも大きく変わります。

実際に、最初自分が書いてしまっていたPostgreSQLクエリ（の見本）を見てみます。

-- スキーマ
CREATE TABLE posts (
    id SERIAL PRIMARY KEY,
    title VARCHAR(255),
    content TEXT,
    published_date TIMESTAMP
);
CREATE INDEX idx_published_date ON posts (published_date);

-- 2024年8月の投稿を取得
SELECT
    *
FROM
    posts
WHERE
    EXTRACT(YEAR FROM published_date) = 2024
    AND EXTRACT(MONTH FROM published_date) = 8;

このクエリには以下の問題があります。

WHERE句の中でカラムに関数を適用してしまっているため、インデックスが効かない。

インデックスが効かないと、行の検索に時間がかかります。データベースの課金額もだいたい処理時間に比例して高くなるので、単純に考えれば10倍遅いクエリを書いてしまったら課金額も10倍になります。

これは比較的わかりやすい例ですが、もっと複雑なクエリを書いたとき、インデックスが効かないケースを見落としてしまうかもしれません。もしくは、もしかしたら今のSQLエンジンはとても賢くて、この程度のミスは勝手に最適化して直してくれるかもしれません。

それを実際に確かめる方法が、実行計画を見ることです。実行計画は、クエリの実行に実際にどのくらい時間がかかるかを教えてくれます。先程のクエリの実行計画(実際の所要時間を含めたもの)は以下のようになります。

詳細は省きますが、インデックスが用いられていないことがわかります。そしてExecution Timeの部分を見ると、実際のクエリ所要時間に64msほどかかっていることがわかります。ここから、より効率の良い書き方でクエリを直すと、以下のようになります。

SELECT
    *
FROM
    posts
WHERE
    published_date >= '2024-08-01'
    AND published_date < '2024-09-01';

所要時間が4分の1ほどになっていることがわかります。こう直すだけで掛かるお金が大幅に減ります。やらない手はありませんね

私がインターンで書いたSQLクエリは、数ある中の一つに過ぎませんが、それでも悪いものを積み重ねると莫大な負債となります。あとから問題に気がつくのも、まとめて直すのもすごく大変なのは、想像がつくところです。今正しい設計を積み重ねていくことの大切さを感じました。

今回のインターンのコードレビューで実行計画を求められたことをきっかけに、数値で計測し、その理由も理解しておくことの必要性を感じました。また、これはトラフィック対処に限りませんが、他の機能の実装を見てみると自分の実装の問題に気がつくこともあり、コードリーディングの重要性も感じました。

確実に正しく動く設計

これまで様々なことを述べましたが、言うまでもなく、サービスが常に正しく動くことも重要です。私が今まで行ってきたサービス開発はどれも小規模なもので、自分自身や周りの人のみがユーザーの、利用者数もデータの数も少ないものでした。しかし今回のプロダクト開発は、それらとはわけが違います。数分でもサービスが落ちたり、ましてやデータが消えるなんてことが起こったらユーザーの信頼を失ってしまいます。

今回のインターンでは、さすがに本番環境を直接壊せる権限までは与えられなかったのですが、参加4日目にして自分で書いたコードが本番環境にマージされるスピード感ということもあり、特に気を引き締めて業務を行いました。

コードレビューや自動テストなどによってもプロダクトの質はある程度担保されるものの、仕組みだけに頼らずメンバーひとりひとりがプロダクトそのものにオーナーシップをもって開発することが大事に感じました。

最後に

今回のインターンで関わってくださった皆様に、この場を借りてお礼申し上げます。私のスケジュールの都合上、就業期間を圧縮しての参加でしたが、お陰でより実務に近い時間を過ごせたと感じています。

参加理由として「エンジニアの一員として働く経験を積む」ということを挙げさせていただきましたが、メンターや他の方々が手間をかけてご指導くださったおかげで、確実にそれを上回る経験をさせていただきました。また、将来の相談といった話も聞いてくださり、これからどうしていくべきかをより深めることができました。

学生の皆さん、忖度なく成長させてくれるエキサイトの実務インターンに、ぜひ応募してみてください！！