こんにちは！サーバーサイド開発部の松田です。
こちらは kubell Advent Calendar 2024 シリーズ 2 12月23日の記事です。
2024年4月に入社してから約半年間、Amazon Aurora MySQL v2のEOL対応を行うプロジェクトに参加しており、そのプロジェクトの中で体感したことをお伝えします。
読者として、「EOL対応の経験がない新卒エンジニア」の方を想定しています。
今回の内容は、「多くの方がEOL対応を経験する中で通られたであろう道を、私も通ることができた」という話になるので、すでに経験がある方にとっては新しい内容はないかもしれません。
では、早速説明していきます！
技術を深く理解するために大切なことは、使い方だけでなく、仕組みやアーキテクチャも学ぶことである
データベースのバージョンを上げようとすると、後方互換性のない変更が追加されたり、あるパラメータのデフォルト値が変わったりします。そのため、お客様にアプリケーションを不具合なく利用いただくためには、アプリケーションでの修正やパラメータの見直しなどを行う必要があります。
例えば、MySQL 8.0ではGROUP BYによる暗黙的なソートが行われないため、並び順を維持したい場合はORDER BYの指定が必要です。 dev.mysql.com
このとき、具体的にどのような修正が必要なのか、その修正による影響範囲の予測、修正後のSQLが十分なパフォーマンスを発揮できるのかを把握するには、仕組みやアーキテクチャを理解しておく必要があります。
ですが、プロジェクト参画直後の私は、「SQLを書いたりテーブル設計など論理的な部分はこれまでやってきたけれど、内側の仕組みとか物理的な部分はほとんど知らないな〜」という状態でした。 なので、一度この機会にリレーショナルデータベースの仕組みやアーキテクチャを学んでみることにしました。
具体的な内容は次のとおりです。
- MySQLやAmazon Auroraを構成するコンポーネントとその役割
- リレーショナルデータベースがクエリを受け取ってから結果を返すまでの流れ
- インデックスの構造やロックの種類
- ACID特性 (Atomicity:原子性, Consistency:一貫性, Isolation:独立性, Durability:永続性)をどのように実現しているのか
- MultiVersion Concurrency Control (MVCC) の仕組みやredo logなどの各種ログの役割
etc…
学んだ結果、リリースノートや公式ドキュメントの理解度が深まったことに加えて、以下のことができるようになりました。
- クエリとインデックスを見れば、ざっくり速そうか遅そうかわかる
- どのパラメータがどこに効いてくるのかわかる
- 各種メトリクスが何を反映しているのか予測できる
- 「データ指向アプリケーションデザイン」で解説されるような、抽象度の高い設計思想と具体例を理解できる
意識的に仕組みやアーキテクチャを学習することで、「使い方」だけでなく、「その技術が得意としていることは何なのか」「特徴的な機能がどうやって実現されているのか」についての理解が深まり、それが業務にも繋がりました。
利用した資料をいくつかこちらに置いておきます。
Amazon Aurora: Design considerations for high throughput cloud-native relational databases - Amazon Science gihyo.jp www.oreilly.co.jp
設計時に運用保守の観点を入れることも重要である
私は大学時代から個人開発や就業型インターン等で開発経験がありましたが、その際に設計時に検討していたことは、
- 機能要件が満たせること
- そのサービスに求められるアーキテクチャ特性を有していること
という観点が多くを占めていました。
しかし、今回のバージョンアップ対応を通して、設計時から運用保守の観点を検討しておくことの重要性を体感しました。 アプリケーションコードの保守性によって、修正コストは大きく変わりますし、インフラ等の管理にも工数がかかるためです。（Amazon Auroraはフルマネージドサービスのため、何度もありがたい気持ちになりました）
具体的な運用保守の観点は、次のとおりです。
- サポートの内容と期間
- インフラの管理コスト
- メンテナンスしやすいアプリケーションコードの設計
長期的にサービスを提供することを考えた場合、運用コストを抑える設計ができれば、「開発速度の低下を阻止する → 浮いたコストを開発に充てることができる → さらなるお客様の価値提供やビジネス価値につながる」という良い流れを生むと知りました。
「自分ならこうする」という意見を持つことが、自己の成長とチームへの貢献につながる
新卒研修が終わった6月から、Aurora MySQL v2 → v3バージョンアップを行うプロジェクトに参加しました。プロジェクトには途中から参加し、わからないことだらけでしたが、いつも「あること」を心がけていました。それは、「『自分ならこうする』を持つ」ことです。
具体例は次のとおりです。
- これからプロジェクトをどのように進めていくのが良いのかについて自分の意見を持つ
- 他のメンバーが着手しているタスクについても、進め方を考える
自分の考えを明確にしておくことで、他者との考えとの差分がわかりやすくなるため、質問や意見が出しやすく、議論を発展させることができます。その回答によって、自動的にフィードバックが得られるため、学びに結びつきやすいと感じました。
また、自分なりの考えを持つためには、十分なインプットが必要です。 今のプロジェクトの状況や進め方・タスクを進める上で必要な知識がない状態では、説得力のある意見は出せず、建設的な議論につながりにくいためです。
自分の考えを持つことで、さまざまな情報を得るためのアンテナが立ちやすくなり、インプットのための強い動機付けにもつながります。
まとめ
私が新卒入社してから半年間で体感したことは、以下のとおりです。
- 技術を深く理解するために大切なことは、使い方だけでなく、仕組みやアーキテクチャも学ぶことである
- 設計時に運用保守の観点を入れることも重要である
- 「自分ならこうする」という意見を持つことが、自己の成長とチームへの貢献につながる
記事は以上になります。読んでいただきありがとうございました！！
