ID:764さん

# 概要 メインチームで開発したゲーム類の運用が縮小体制になった後に、 全体インフラチームに参画して、他組織が運用していたゲームを一括で 動作させているサーバー群の運用などを対応 # 主担当 - サーバー運用（監視・異常時対応・更新など） - 不定期に、このインフラで可動しているサービスの機能追加にも参加 # 技術スタック - PHP: Webアプリケーションとして。ZendFrameworkをベースにした、社内開発のフレームワークを利用 - Apache: Webサーバーとして。 - NFS: Webサーバー台数が膨大だったため、コードのデプロイ先として運用。Webサーバーはこれをマウントする形式 - MySQL: DBサーバーとして。サービスに応じて個別にmasterを持ち、slaveのみ単一サーバーで集約 # 主な課題など ※ウェイトの高かったサーバー運用系でのトピック ## バックエンドソースの実装に起因する性能劣化とその対応 リクエストによって、レスポンスに大きなばらつきがあることを検知。 単純なNFSによるネットワーク通信などがボトルネックだったわけでなく、 コンポーネントのインポート処理に起因するものであると診断検知した。 ### 解決について 当時はcomposerやautoloadingなどの実装を用いておらず、 もっぱらrequire/includeなどの関数を使ってクラスのロードなどを行うスタイルだった。 この際に、内部処理として多数のクラスソースをrequire_once()を用いてインクルードしていたのだが、 インクルード済みのものをインクルードしないためのこの処理は単純なrequire()と比較して、 明らかに性能が出ないことがわかった。 インクルードを行う処理群がエントリーポイント序盤に1回しか呼ばれないことが確認できたため、 require_once を requireに差し替える改修を行い、最終的にレスポンスタイムを安定的に短縮できている。 ## PHPバージョンの更新 サーバー自体が比較的古い歴史のアプリの時期からのもので、 PHPのバージョンが古くEOLを超えており、 「セキュリティFix」「パーフォーマンス改善」を目的にバージョンアップを実施 当時はQAチームや定常的な動作検証ケースなどがなかったため、 以下のフローで実施。（基本的に自分のみで対応） - 更新前後のバージョンのデフォルト設定を比較して、旧バージョンに寄せる設定内容を策定 - 開発・ステージング環境の更新を行いアプリケーションレベルのログ内容をチェック→改修依頼 - 致命的になりうる部分を対処後に、本番環境に1台だけ導入してログを負いつつ最終確認 - 問題ないことを確認後、全台適用 最終的にパーフォーマンス改善がかなり大きかったらしく、 同時期で最大90台同時稼働していたWebサーバーが、同じPV相当で20台前後で処理できるまでに改善した。

# 概要 社員証・入館証などに使われているNFCを利用して、 社内・グループ内イベントにおける、受付と出席記録を行うシステム # 主担当 設計〜開発〜運用全て（企画を除く） ## 企画を除く理由 この主旨のシステム自体はグループ内の別メンバーが開発したものが存在しており、 システム終了に伴い要件定義レイヤーの部分だけ引き取る形での提供が始まったため （基本的な動きをフォローアップした上で、ソースコードの提供は受けない条件だった） # 技術スタック ## バックエンド Python製WAFのDjangoをベースとしたWebアプリケーション。 WebsocketによるFE/BEの連携を行い、バックエンドでカードの認識・識別・出席判定を行って、 結果をsocket経由で通信する仕組みをとっている。 使っている主要なライブラリは、Django、Django Rest Framework、Django Channels、nfcpy、SQLite3。 ## フロントエンド イベント受付時の待受画面以外は、Bootstrapのみを使用したシンプルな画面。 待受画面に関しては、バックエンドで動いているnfcpyとの連携と多少インタラクティブな画面が要求されたため、Vue.jsで実装した。 ## 動作構造 PC単体で動作することを基本設計としており、ローカルで起動したサーバーにブラウザでアクセスする形式が基本。 これに加えて、LAN内にサーバー役の端末を用意することで、協調動作するようにもなっている。 # 主な課題など 移管元のシステムが運用時に揚がっていた要望として、 「現在の全体受付人数を知りたい」というものがあった。 この要件をクリアすることためには、受付記録の保存先を統合出来るようにする必要があり、 特定の端末単体を中心のサーバーとして運用する必要があった。 これに対して、USBカードリーダーは各クライアント接続が必要で、 なおかつブラウザ上から操作する手段が無かったため、 - カードリーダーの制御はローカルサーバーの機能として実装 - リーダーの結果を元にしたサーバー間通信は、サーバーがそのまま担当 - 中心となるサーバーをAPIと見立てて、結果を受け取り、Websocketを通じてブラウザに表示 というロジックを取ることで解消している。

# 概要 プロジェクト4にて記載している「グループ内の内イベントの出席記録システム(1)」の後継版。 ※技術スタックが大きく乖離しているため、別プロジェクトとして記載 ※安定運用前のフェーズとして、社内限定で運用 # 技術スタック Firebaseを用いた、サーバーレス構成によるSPA。 - Next.js - Firebase Hosting - Cloud Functions for Firebase - Cloud Firestore - Web USB API # 主なトピック ## FirebaseとCloud Functionsによる受付API バックエンド系の動作環境をFirebaseにしたことにより、 認証基盤周りのスリム化とデプロイの容易さを実現した。 ## Web USB採用による受付可能端末の大幅増加 前システムは、nfcpyが動作できるPCで有ることが前提となっており、 可搬性に大きな問題を抱えていた。（待受台数が増えるほど必要なPC台数が増えて重量がかさむ） 再設計のタイミングで、Google ChromeがWeb USB APIを利用可能になったことがきっかけで、 カードリーダーとの通信をブラウザで処理する設計に変更し、 「カードリーダーの読み取り->受付処理用API通信->受付結果の表示」を ブラウザのみで全て完結する構造になり、なおかつAndroidでも動作するようにした。 ## WebUSBAPIの処理系をライブラリすることによる、社外での案件獲得 Web USB APIはブラウザで端末に接続されたUSBデバイスと通信するための規格となっている。 そのため、前システムで使っていたnfcpyをほぼベタ移植気味に行うことで、 ライブラリとして使えるように実装した。（コードはTypeScriptで実装） 結果として、このライブラリを流用することで、社外の面接官受付システムを 超短期間で開発・納品をした。