はじめに
新卒でエンジニアデビューして4年目になりました。
1年目の私は、linuxって何？sh...ell...?SQLは研修でやったような...?な状態でWAS,DB2を扱うプロジェクトにアサインされました。何をやればいいかわからず、手あたり次第にタスクへ立ち向かっていたのを覚えています。笑
4年目になって流石に右と左がわかるようになり、"できること"や"(少し勉強すれば)できるかもしれないこと"が増えてきました。一方で、"(キャリアとして)やるべきこと"や"(かなり勉強しないと)できないこと"から目を背ける機会も増えてきた気がします。成長を頭打ちにさせないためにも、ここまでの道のりでよかったことを整理して次のチャレンジをしていかなくてはと思うようになりました。
そこでゼロからスタートするならば、何から始めるだろうという視点で3年間を振り返りつつ、その手記をまとめておこうと本記事を執筆することにしました。
本記事は、技術記事というよりWASやDB2と向き合うことでエンジニアとして成長した経験をまとめながら、自分が"できること"を明確にしていきつつ、新人から中堅へ向かう登山道の一例として、新人の方の参考となるかもしれないエッセイだととらえていただければ幸いです。
（記事の途中には、WASやDB2の技術的な小ネタを含んでおります）
想定する読者
・ キャリアの進め方に迷われている新人エンジニアの方
・ WAS,DB2とこれから向き合っていく方
・ 新人時代を思い出してそんなことあったなぁと懐かしんでくれる方
ゼロから始めるエンジニア生活、何からスタートする？
さて、本題です。3年間を振り返ってみて、成長したなと思う瞬間はいつも障害の近くにありました。
それはコードを書いている時でもSTをしている時でも変わらず、バグに対応しようとすることで製品やコードに対して一段と詳しくなる瞬間があります。一段深く知れると仕組みが見えてくるので、自分でやっている勉強の理解度も上がり学習意欲も高まっていたなぁと思います。（今思うと、無意識ですが、進んで障害対応を引き受けていた時もありました。）
エッセイ風という話だったのでいくつかの障害調査のケースを引き合いにだして振り返ろうと思います。
※本記事はWAS,DB2関連の障害調査の内容になっております。公式ドキュメントや関連記事が多いことで、製品の歴史が長い恩恵を受けて障害調査の難易度が低くなっているなぁと感じております。
case1 デバフがかけられたかと思った性能劣化
これは、DB2関連の障害ですね。
いくつかのSELECT文が遅延していたため性能要件を満たさないという事象でした。
「SQL 遅い」でGoogle先生に聞くと沢山の改善Tipsを教えてくれますし、ChatGPT先輩は以下のように回答してくれました。
SQLのパフォーマンスを向上させるためには、いくつかの可能性があります。以下は、SQLクエリのパフォーマンスを向上させるために確認するべきポイントです。
1. インデックスの作成：テーブルにインデックスがない場合、クエリの実行に時間がかかることがあります。必要な列にインデックスを作成することで、検索の速度が向上します。
2. クエリの最適化：クエリの最適化により、クエリの実行時間を短縮することができます。クエリの書き方を見直し、最適化することで、クエリのパフォーマンスを改善することができます。
3. テーブルのパーティショニング：大規模なテーブルを使用している場合、テーブルをパーティション化することで、パフォーマンスを向上させることができます。パーティションを使用すると、大量のデータを高速に処理することができます。
4. ハードウェアのアップグレード：パフォーマンスの問題がある場合、ハードウェアのアップグレードを検討することができます。データベースサーバーのCPU、メモリ、ディスクなどのアップグレードが考えられます。
5. クエリのキャッシュ：クエリのキャッシュを使用することで、同じクエリを複数回実行する必要がなくなります。データベースエンジンがクエリをキャッシュするように構成することができます。
これらの手法のうち、最初に検討すべきは、クエリの最適化とインデックスの作成です。最適化されたクエリと適切に構成されたインデックスを使用することで、パフォーマンスを大幅に改善することができます。
この中で私が注力したのが、「クエリの最適化」 でした。
色々なコマンドを投げては時間を計測して、試行錯誤していた記憶があります。笑
大学時代の物理実験の気分でした。
最近のオプティマイザは優秀ですから、巷で出回っているクエリの最適化が通用しないことは多々あります。クエリの最適化のために私は以下の手順で性能遅延と戦うようになりました。
- 遅いSQLを捕まえる。（dsmtopコマンドやMON_GET_PKG_CACHE_STMTの確認等でSQLを探します。）
- 遅いSQLの実行計画を取得する。
- 実行計画からオプティマイザが発行しているSQLを抽出する。
- 上記SQLの中で演算に時間がかかりそうな部分を分析する。
- 修正したsqlを投げて3~5を繰り返す。
そうこうしているうちに、SQLのチューニングなら自分でもできるかなと自信がついてきたように思います。一つでも自分でできることが増えるとやはりモチベーションにつながりますね。
（余談ですが）SQLだけでなく、時間の計測はlinuxコマンドに対しても行ってました。
この記事で説明してますが、これも1つずつコマンドを打って何が早いかを実験してましたね。笑
sqlのチューニングとlinuxコマンドのチューニングはこの時書いた汗のおかげでかなり得意になりました。
case2 無限に増長するメモリ（アウトオブメモリ）
アウトオブメモリに初めて出会ったときに、ソフトウェアの中身に触れた気がします。
アウトオブメモリの仕組みを調べ、メモリリークをウォッチするためにGC.logを眺められるようになり、Java系のアウトオブメモリだったので、Javaのメモリリークの原因を調べるためにコードを眺め。。（当時、Javaなんてそんな詳しいわけじゃなかった。。。）
この障害から学んだのは、ログを眺めることの大切さでした。
システムがいろいろな場所にログ（ SystemOut.log、SystemErr.log、trace.log、native_stderr.log、native_stdout.log など）を出力していると思うんですが、これらを眺めると本当にいろんなことが書いてあります。呼吸を極めれば様々なことができるようになるというのと同様に、ログを極めると様々なことがわかるようになります。
最初はお恥ずかしながら文字の羅列で読むのを敬遠していたんですが、ちゃんと英語で書いてあるので読もうと思えば読めます。最初はひとつずつの意味を調べていく感じでしたが徐々に景色が広がっていきました。そこからEJBやトランスポート・チャネル・サービスといった用語に触れていく機会になり、意味は分からないなりにソフトウェアの内側を知るきっかけができました。普通に面白かったし、適切に使えるようになりたいなぁと思ってます。（今も思ってます。）
case3 ちりも積もれば山となるメモリ逼迫
最後は、slab_cacheのメモリリークです。
これはメモリ周りの勉強になりました。本当に。調べた記事を読みながら自分なりに発生のメカニズムを追いかけていました。仮説を立てては調べ、ドキュメントを漁り、、、というのを繰り返して障害調査をやってました。case1,case2は割とメジャーどころだったのに対してcase3は結構細かい障害だったので、障害原因を追い詰めるのに少し時間がかかりました。
しかし、この障害をちゃんと把握できたのはとても自信になりました。ただ、個人的には思い入れの深い障害なんですが、あんま振り返ることがないんですよね。研究でやっていたことをそのまま障害調査に当てはめたというか。。。既に知っていることが絶対的な正義だと思いますが、うーん。これはどうなんだろうか。。どこまで既知であるべきだったかとか、障害調査にかかった時間はもっと早くできたんじゃないかとか思いますが、あまり体系立ててアプローチした記憶がないですね。
そもそもこれを起こさないロジックでつくるようにするとか、ログ出力やアーキテクチャの自分なりの哲学的なものをアップデートする機会として活用するような養分として利用したことが強いイメージに残ってます。
障害調査って基本的には半面教師的に自分のシステム哲学をアップデートするところまでが一連のフローになるのが正しいのかもしれないですね。。
まとめ
case1~3と振り返ってみて、時々でレベルアップしているなぁと思う反面、case3の言語化が曖昧だったことに少しの気づきを得られ、case4へ向けて準備を進められる光明が得られました。
障害調査を起因とした転生をしながら良いシステムがつくれるエンジニアへと成長していきたいです。
（とはいえ、障害ばっか起こしていられないので、QA活動も並行して強化していきたいです。。）
入社当初はエンジニアといえば「コードを書ける人」というイメージでしたが、一口にエンジニアと言っても様々な能力が求められます。
もちろん、"クリーンなコードが書ける能力"も求められるスペックの一つです。それ以外にも、"品質の高いシステムを作れる能力(Quality Assuarance的な)"、"ベストプラクティスなアーキテクチャを作れる能力","最新技術をOverAllに説明できる能力"など。
全ての能力を身につけられるのに越したことはないですが、なかなかフルスペックを超えたフルスペックになるのは一足跳びでできるようなものではありません。求められる能力を一つずつ身につけて、成長させていくしかないです。
オブザーバビリティエンジニアリングの本を読んでいる際に、オブザーバビリティ性の高いエンジニアは好奇心を持ってシステムの障害に立ち向かえるというようなニュアンスのフレーズがありました。だからこそ、システムに詳しくなるし、挙動を深くまで説明することができるのだと。
今回の障害調査から始めるエンジニア生活で何の能力が身につくかというと、この「オブザーバビリティ的な能力」だと思います。そして、この能力は、いつか出世してシステムの中身を触らなくなった時にでも、おかしいことおかしいと気付けるための能力だと実感しております。
エンジニアとして身につけなければいけない能力は様々ですが、新人エンジニアの方には是非、オブザーバビリティ的な能力を養っていただければと思います。