ID:13832さん

企画当初の開発立ち上げ期から参画しました。開発はバックエンドを中心にフロントエンド・インフラと全般を行なっています。 立ち上げ当初はPHP/CakePHPを採用していましたが、新しいことへの挑戦とプロトタイピングに有用と言われていることを知っていたためスピード感を重視して、Ruby/RubyOnRailsを採用し開発を始めました。2018年12月ごろ、リニューアルを行った際は、フロントエンドReact/Redux、バックエンドRuby/RubyOnRailsを採用しました。またデザインからフロントエンドの落とし込みを早める・再利用性を高めるため、AtomicDesignの概念も適応しました。 アプリケーションとしては、フロントからAjaxでAPIを呼び出し、データはMysql/S3を繋げる一般的なものです。一般的ではありますが、初期レスポンスは30msほどで動く仕様になっています。 コンポーネントはフロント・API・バッチと分けて開発しました。 分けて開発することで、今後人員が増えてきた時のリソースの配分と開発範囲が明確にできます。

【データベース確認指標のモニタリング】 システムの言語はPHP、サーバは CentOSとFreeBSD、データベースはOracleを主には利用していた広告の運用を任されていました。 特にデータベースを管理することが多く、データベースへのメモリ・CPUの増加での逼迫による各アプリケーションの遅延が起こることが頻繁に起こっていました。 元々は事前察知もなく、急に遅くなる。わざわざデータベースにログインして調査するなどをしていました。 データベースへの接続悪化の原因となるメモリ・CPU使用量だけでなく、セッション数などを一定間隔でデータを取り、閾値を超えるとアラートをあげて、重大なインシデントになり得る可能性が高いことを事前察知するようにし、何か異常があったとしても即時対応できるようにしました。 アラートをあげるだけでなく、データを可視化することも highchats.js で行い、メンバーが見やすい形式にもしていました。またモニターに常時表示することで、データベースにログインしなくても時折歩きながら、チームの誰かが見ると事前察知ができました。 データベースが悪化していることについては、当時初心者であったため、チーム内の詳しい人に教わりながら作成しました。コーディングはレビューをしてもらうだけでした。

複数チーム・コンポーネントが存在していて、アラート検知・アラート対応方法の集約をするために作成されていたツールを改善していました。大枠は私に開発・保守を引き継ぐ前はアラート検知の集約はされていました。ただ、アラートログが複数サーバから同じようなものを検知した時にサマリーを作るなどができておらず50%ぐらいの出来のシステムでした。 アラートログのサマリーについては、対応完了する時に対応したログを記していくのですが、同じものは同じ対応方法なので、一括で保存する必要があります。一般的に近しい時間以内にあるログをサマリーを作って、一括で更新できるようにしました。ログのサマリはSolrを活用して作成しました。 ツールの改善を行うことでよりユーザにとって使いやすい形にすることが目的であったため、ハードに利用しているユーザにメールと面談で聞き込み調査をしました。調査結果で要望数の多いものを優先度高くし、アップデートしていきました。アップデートの前には、ローカル開発したUIと使い勝手を確認して、修正したのちリリースしていました。 この一年で作成し終わり、アップデートなしに利用継続されているそうです。