一見重要に見えないけど大規模開発では必須！パフォーマンスチューニングを執筆したワケ【著者インタビュー】
インタビュイー紹介
鈴木翔大 氏。東京都在住のフリーランスエンジニア。車両の位置情報を管理する高トラフィックサービスやユーザー数100万人超の大規模サービスなどの開発・運用を経験。得意な技術はRuby on Railsで、rails 含め複数のOSSのコントリビューター。
こんにちは。Techpitの辻岡です。
今回は、Techpitの執筆者の鈴木翔大さんに、なぜN+1対策のテーマを執筆されたのか、過去のご経験を元に執筆に至るまでの想いをお聞きしました。
1. N+1対策は動く上では問題ないけれど、プロダクトとしては重要である
開発・OJT研修の経験を元に、N+1対策のテーマを執筆
ー 鈴木さんはTechpitでどんなテーマを書かれましたか？
N+1が発生しない堅牢なコーディングや解決方法を執筆しました。N+1起因でパフォーマンスが悪化している状態のRailsアプリケーションに対し、ハンズオン形式で実際にチューニングを行い、N+1問題を解消していくテーマです。
業務の経験で話すと、実務でN+1の解消やOJTでの研修指導の経験があります。開発実務の中では、過去携わったプロダクトで、サービスが急成長してパフォーマンスが顕著に落ちるようなことがありました。そして、パフォーマンスが落ちるとプロダクトとして良いユーザー体験を提供できじゃないですか。なので自分でN+1を解消したり、誰かに教えたりして、チームでN+1を解消してきました。
そもそも市場に学習機会が少ない
ー なぜそのテーマに決定したのですか？
N+1の知見は、アプリケーションの規模にかかわらず重要で、初心者から中級者まで必須のスキルだと思っています。ただ実際に現場で初学者と開発を行うと「現場で使う知識」が不足していることを見受けられます。
その原因はRailsアプリケーションの基礎的な部分を学習できる記事や教材が割と多いけれど、一方でN+1を学ぶ機会が少ないのでは。また、新卒研修シーンでも学ぶ機会が不足していると感じました。過去参画した企業ではプログラミング研修を行ってましたけれど、N+1問題に十分な時間を割けていませんでした。
なぜパフォーマンスチューニングは大事なのか？
ー パフォーマンスチューニングを怠ると、どのようなことが起きるのでしょうか？
ただユーザー数が多くなることでトラブルが発生し、ユーザー数が大きい分、ビジネスに与えるダメージは大きいです。
一応、補足で紹介するとGoogleの論文では以下のように発表されています。
表示速度が1秒から3秒に落ちると、直帰率は32%上昇する。 表示速度が1秒から5秒に落ちると、直帰率は90%上昇する。 表示速度が1秒から6秒に落ちると、直帰率は106%上昇する。 表示速度が1秒から10秒に落ちると、直帰率は123%上昇する。
出典：
実際、初めてパフォーマンスが悪化したことでトラブルに遭遇したときはびっくりしました。ただシステム要件としては、どうしてもパフォーマンスチューニングの優先度は下がってしまいます。とはいえ、いざ起きた時は緊急性が高いので、予めパフォーマンスを意識して開発することは大事だと思いますね。
大事さに気づけていない要因は？
ー なぜ重要なのに学ぶ機会が少ないのでしょうか？
プログラミング学習者さんは、動かすことに全力を注ぎ、パフォーマンスを意識している方は少ないかと推測しています。あと、学ぶ本人の問題だけでなく、教える側もパフォーマンスの話は少ないと思います。個人的にはまず教える側が、重要だから教えてもよいのでは。
ー とはいえ学習のステップがあると思います。パフォーマンスチューニングを学ぶタイミングはいつ頃でしょうか？
Ruby on RailsでCRUDなど基礎を習得したあとが良いのでは。現場で働く前から実際に手を動かしてたくさんのパターンを覚えていくのが理想かしれませんね。全員が全員という訳ではないけれど、世の中のプログラミング学習者の多くの方が、最低限の文法や理解が中心に学習している印象を持っています。
一方で実務だと求められるのはビジネスとして成り立つシステム構築のスキルです。もちろん動かすことは重要ですけれど、動くものを実装するだけでは難しいのも事実としてあります。
またRuby on Railsの開発の現場で働く際は、新規ではなく既存サービスの案件や企業が多いという認識です。なので既存のサービスを壊さないプログラミングスキルが必要になってきます。
ー ちなみに小さなアプリケーションを実装することで気になったことがあります。小規模アプリケーションの時はパフォーマンスチューニングを考慮しなくても大丈夫かなと思いましたが、いかがでしょうか？
小さなアプリケーションの使用用途によって意見が変わりますけれど、基本的にアプリケーションが小さい時ほどコストが少なくて済みます。なので、小さいからといって無視しても良いという訳ではありません。
というのも負債を小さくする意味で重要です。N+1というのはざっくりいうとデータの数が増えてくる事でパフォーマンスが落ちてきます。事業・プロダクトの成長につれてボトルネックになってくる。
けれどサービスが大きくなるとシステムが複雑になって修正がつらくなったり、トラブルがあったときのダメージ・リスクが大きくなってきたりします。つまりアプリケーションが小さい時ほどコストとリスクが小さいです。
また工数の問題もあるけれど、きちんと理解していれば実は楽でコスト少ないです。また余談ですけれど、Ruby on Railsはパフォーマンスが出ないという風潮があります。
しかしWebサービスに求められるパフォーマンスはRuby on Railsで十分発揮できると私は思う。実際にパフォーマンスが良いサービスも存在するので。ここに関しては正しい知見を持っている方が少ないのかと思います。
図解で丁寧に解説
ー 今回パフォーマンスチューニングのテーマを執筆する際、どんなことを意識して書かれましたか？
初学者さんが挫折しないよう丁寧に進められることを念頭に、N+1自体の理解する章では、画像を用いて説明することでイメージしやすいように工夫しました。初学者さんは、『メモリにキャッシュされるクエリの実行結果』など、目に見えない・コンピュータサイエンス的な挙動部分を想像しにくいかと思います。なので難しく考え込んで挫折しないために、画像を用いてイメージしやすくすることを大事にしました。
▼画像の使用例
ケーススタディでリアルなパフォーマンスチューニングを解説
実はもう一つ工夫したことがあります。それは実践を想定して思考プロセスまで解説したことです。メソッド選定の思考プロセスなど開発現場でリアルに起きうることを取り上げました。
具体的に伝えると、教材の2-2「3. コード修正」という箇所の話です。メソッドを網羅的に荒い出して、「このケースではこのパターンに当てはまる」という理論を立てて選定するといった思考プロセスを解説しております。
また無料でプレビューを閲覧できますので、ぜひ下記の見ていただけたら幸いです。
そして、思考プロセスの工夫について受講者レビューで高評価をいただき、しっかり価値を届けられているのかな？と思っております。
▼学習者利用者さんの声
2. 『技術力×執筆力のブランディング』がTechpitへの参加理由
ー ところでなぜブログなど様々なアウトプットの場がある中で、Techpitで執筆することにしたのですか？
プログラミング学習に特化したプラットフォームというのが大きかったですね。私自身のキャリアが独学からのスタートになっており、同じ独学からエンジニアを目指す方の力になれることに意義を感じています。また、アウトプットの場として、個人での活動場所よりも多くの方に著作物を認知していただけると思ったため、Techpitで執筆を決意しましたね。その過程でセルフブランディングの効果にも期待がありました。
セルフブランディングの話
ー どういった感じでTechpitがセルフブランディングになるとお考えですか？
Techpitは、盛り上がっているサービスじゃないですか。例えばTechpitがTechCrunch等に掲載され、世の中から注目されていたり、他にもTechpitの執筆者専用のSlackに、業界で有名なエンジニアや知人のエンジニアが参加していたり、ボジティブなイメージがあります。なので、そういった盛り上がっている場所で活動することは、セルフブランディングに繋がるのではないかと考えています
またTechpitはお金を払ってでも読みたい明確な読者が存在するので、人に技術を上手く伝えるスキルのレピュテーションをもらえそうというイメージもありまね。もう少し端的にいうと、Techpitで執筆すると、技術力×執筆力のブランディングに繋がるかと思いました。
実際に執筆してみて、バイネームで「この教材良かった」や、教材のツイートに対しいいねとフォローのセットで反応をもらうなど、ソーシャルな場でのポジティブな反響がありました。ただ「新しい仕事がつながった」等はないので、まだ多くの方が期待するほどのセルフブランディングに繋がっていないかもしれませんね。
ー ちなみにセルフブランディングの一環で他にチャレンジしたことはありますか？
RailsのOSS活動やQiitaでのアウトプット、LT登壇などを行ってきました。セルフブランディングの話でいうなら、一番反応が多かったのはOSSのコントリビュートです。実際OSS活動自体についてよく聞かれますので、OSSはエンジニア界隈で評価されているかと思いますね。またLT登壇はある程度反応が返ってきますけれど、登壇機会が少ないことがボトルネックです...
3. 執筆は小さく確認した方がスムーズ
ー 執筆で苦労した点はありますか？
テーマ自体が難しい内容だったので、どう分解して説明するか、どうやってイメージしやすくするかに時間を注ぎました。また教材自体の進め方、ストーリーをどうすればより良く学習できるかも同時に考えましたね。
ー イメージしやすくするために具体的にどうやって乗り越えましたか？
まあ考えるだけって言ってしまえばそれだけですが、運営の編集担当の方にSlackで小さく確認していくことが乗り越えられた要素かもしれません。というのも体系的な執筆は初めてだったので、正直悩むことが多かったです。その際に、素案で投げて小さく確認して進められたのは良かったかもしれませんね。
ー 例えばどんなことを相談したのですか？
確認しておいて良かったことで言えば、教材自体のストーリーの方向性です。他には教材のアプリケーションの構成や途中の章立ての変更を検討しました。進めながら適宜微修正、小さく確認&スピード感のあるレスポンスでスムーズでした。
教材のストーリーは、下記のような2つのアプローチを検討しました。
1. 既存のアプリケーションがある状態から改善していく
2. 新しくアプリケーションを開発しながら防ぐ
確認前時点では、2の新しくアプリケーションを実装しながら教えていくストーリーを検討していました。
ただ、既存で改善しながら選ぶメリットもありました。例えば、1つは95%のパフォーマンス改善ができることです。数字で証明でき、結果が顕著なのでよりイメージがしやすくなります。2つ目は、新規のアプリケーションで導入すると、導入しなかったケースとの比較ができず、パフォーマンスチューニングの必要性がわからなくなること。
▼ストーリーの相談(執筆に参加初日の出来事)
そして既存のアプリケーションを改善していくメリットに気づいて、始動する前に運営に小さく確認できたことが執筆をスムーズに進められたのかと思います。方向性をあとで修正しようと思うと莫大な工数がかかることを考えると、少し気になる程度で早めに相談できたことは良かったです。
あと執筆当時はゴールデンウィークだったのに、相談の返答やレビューのレスポンスが非常に早いため集中力を維持したまま取り組めました。声をかけることに気にする方もいるかと思いますけれど、個人的にはどんどん運営の人に相談していくと良いと思います！
4. 挫折せずに読み返してもらえる教材になれたらうれしい
ー 教材を通じて実現したいことはありますか？
初学者は挫折しないよう丁寧に進められること。また中級者も実際に開発するときに迷った際、この教材を読み返し適切な解決が行えるように意識して執筆したので、そういう風に利用してもらえたら嬉しいですね。
ー 読み返しというのはいわゆるリファレンス的な役割かと思いますが、どの辺にリファレンスとして役割があるとお考えですか？
基本から実践まで網羅的な内容を執筆していますので、辞書的な振り返りとしての役割であったり、問題解消の思考プロセスを書いているので「あの教材ではどういったプロセスで解決していたのか？」みたいな感じで振り返りの要素があったりするかと思っています。
一応、今回の教材は下記のような構成で執筆しています。
1章：基礎
2章：メソッドの選定・ケーススタディー
3章：複数テーブルの対処法
1章の基礎では、メソッド名を、メソッドのメリットがわかりやすいように表形式で一覧にして紹介しています。なので、N+1ってなんだっけ？みたいな場面でリファレンスとして活用いただけるのではと思います。
▼メソッド一覧の紹介例
そして、2章ではケーススタディをメインに思考プロセスも書いています。なので少しシチュエーションが異なっても、解決に役立つのではないでしょうか。どうやってメソッドを選ぶんだっけ？という悩んだ場面で、どういう風に考えているかの振り返りお使いいただけたら嬉しいですね。
辞書的にも、思考プロセス的な意味でもでリファレンスとして役立つと自負しています。
あと教材とは関係ない話になりますけれど、近年N+1の必要性も高まってきているかと思います。実際Railsの次期のバージョンでN+1発生を抑止するための追加機能が準備されています。
これまで新卒研修など一般的な学習サービスで注目されていなかったけど、こうして組み込まれるということは、必要なシーンが多くなってきてニーズが強まっているのでないでしょうか。
なのでこれまでフワッと理解していた人がN+1を意識するようになり、その際にで必要であれば私の教材を手にとっていただきお役に立てたら嬉しいです。
編集後記
以上、鈴木翔大さんの取材となります。最後まで読んでいただきましてありがとうございます。
取材中、過去のご経験から一貫してパフォーマンスチューニングが大事だという想いが伝わってきました。今回の記事を通じて、鈴木さんの想いが伝わり、鈴木さんのご経験が皆様の新しい発見につながると嬉しいです。そして新しい発見・学びがありましたら、ぜひTwitterでご感想をくださいませ。
▼鈴木さんが執筆された教材
▼執筆してみたい方は下記よりご応募ください
この記事が気に入ったらサポートをしてみませんか？