Technology & Design Department の Engineering Section に所属している水野 (id:zuno_onuz) です。
フルリモートワークを始めてもうすぐ2年が経過しようとしていますが、腰痛に悩み始めてきました。
日々の通勤で結構な運動になっていたことをひしひしと感じるこの頃です。
さて、今回は2021年におこなった業務として、技術的な改善に絞ってふりかえりました。
既にうろ覚えな改善もありますが、先に社員の皆さんと協力して箇条書きしたので、いくつか選択して紹介いたします。どうぞよろしくお願いいたします。
改善したこと
ランディングページの配信に静的サイトホスティングサービスを利用
バレットグループでは多数のランディングページを運用していますが、ほとんどが WordPress を利用して構築していました。
しかし、WordPress での構築には下記のようなデメリットが挙げられました。
- 構築・運用の工数やコストがかかる
- KUSANAGI を利用して WordPress の構築をしていたが、バレットグループのセキュリティガイドラインの反映に多くの工数を割く必要があった
- 運用開始後もサーバー監視や WordPress プラグインのアップデートが必要になり、ランディングページの増加により運用の工数も比例して増加
- ランディングページはたくさんの画像を載せることが多く、それなりのスペックが必要になりインスタンス費用がかさむ
- ページの描画が遅い
- WordPress はデータベースからデータを取得してサーバー側で描画するため、表示まで時間がかかることがあった
- セキュリティリスクが高い
- WordPress は高いシェアを持つため、攻撃の対象として狙われやすい
- プラグインの脆弱性が放置されていることもある
上記のようなデメリットを軽減するために、用途に合わせて様々な静的サイトホスティングサービスの利用を進めていきました。
実際に利用したサービスは下記になります。
- Cloudflare Pages
- Amazon CloudFront + Amazon S3
- Netlify CMS
Cloudflare Pages を題材にした記事を id:Usek さんが執筆されていますので、ぜひご覧になってください。
Datadog 導入によるアラート集約
これまで検知したアラートを手作業で Google スプレッドシートに転記して管理する IT エンジニアらしからぬ作業をおこなっていました。
この作業を数年おこなっていたわけですが、転記漏れなどのヒューマンエラーが発生し、信頼性が損なわれて分析に影響が出ていました。
そこで、Datadog のインシデント管理機能を利用し、検知したアラートを集約することにしました。
CloudWatch Alarm で発生したアラートを検知し、 SNS を介して Lambda を起動して Datadog の API を実行することでインシデントを作成しています。
上記の流れでアラートを Datadog に自動で集約し、トイルを軽減することができました。
管理画面のデザインリニューアルに伴うシステム構成の変更
BGテクノロジーにて運営している成果報酬型プラットフォームの SLVRbullet で、2020年4月に管理画面のデザインリニューアルプロジェクトが始動しました。
デザインは外部の企業様にご依頼し、綿密な打ち合わせのもと、素敵なデザインへと生まれ変わりました。
デザインの詳細に関しては Design Section の皆さんに執筆をお願いすることになっていますので、残念ながら今回は省略させていただきます。
せっかくなので、ログイン画面の before after のみ掲載します。
本題に入りますが、本題も別で詳細に執筆する予定となっているため、掻い摘んでお話します。
当初は既存のアプリケーションの View をそのまま変更する予定でしたが、デザインのリニューアルによる UI の変更や、新規機能の追加が必要なことも徐々にわかり、一筋縄では行かないことがわかってきました。
加えて SLVRbullet では下記のような問題を抱えていました。
- 重要な機能のパフォーマンスが悪く、表示までに時間がかかる
- Controller にビジネスロジックがずらずらと書かれている
- 言語やフレームワークのバージョンが古く、サポートが対象外になりそう
- 開発環境、検証環境、本番環境で環境の差異があり、予想外のエラーが発生しがち
このようにデザインだけ切り替わっても、パフォーマンスは変わらず、改善すべきところが改善できていない状況で進行するのはよろしくないと考えました。
そこで「このタイミングでリプレイスしてしまおう！」と思い立ち、デザインのリニューアルと共にシステム構成の変更も同時に始動しました。
具体的には別の記事で説明する予定ですが、フロントエンドとバックエンドを分離し、すべての環境をコンテナで管理するように変更しました。
無事デザインリニューアルとシステム構成の変更のどちらもリリースが完了していますが、上記もひとつの起因として悲劇がいくつかありました。
自責の念を込めて、いつか執筆できればと思っています。
PHP のエラーレベルの設定を見直し
弊社が保守しているアプリケーションに、いくつか素の PHP で実装しているアプリケーションがあります。
該当のアプリケーションで Nginx のエラーログを確認して調査しようとした際に、E_NOTICE のエラーで埋め尽くされてしまっていて、設定漏れがわかりました。
エラーの見直しのついでに、本番環境のみ E_NOTICE のエラーを Nginx のエラーログに出力しないように変更しました。
初歩的なミスや漏れって以外と気付けないことがありますよね・・・。
変更方法は簡単で、設定ファイルの error_reporting を以下のように修正しました。
error_reporting(E_ALL & ~E_NOTICE);
調査の手間になることは少しずつ排除していきたいですね。
その他の改善
せっかくいくつか箇条書きしていただいたので記事に載せておきたいと思います。
- メールフォームの実装を構成管理ツールを用いて工数の削減
- チケット管理システムを Jira Cloud に移行
- Git ホスティングサービスを GitHub に移行
- データベースの遠隔バックアップ方法の改善
- AWS Certificate Manager の認証方式をメール認証からドメイン認証に変更
- FujiSSL GO を利用し、証明書の自動更新
- デッドロックが発生したときにログを出力するように改善
- Pull Request に SQL の実行計画を載せてパフォーマンスに気を配る
- 使用しているライブラリの OSS ライセンスを一元管理
最後に
ふりかえってみると今年は濃い一年であったと感じました。
自分が担当していなかった対応の理解にも繋がったので、機会があればまたまとめてみたいですね。
