【GIG勉強会Vol.66/GIGLT.54】2022年にGIGエンジニアはこんなこと頑張った！ 検索処理高速化からPHPカンファレンスまで

こんにちは！ 株式会社GIG 広報の宮﨑です。

GIGでは毎月さまざまなテーマで勉強会を開催しており、現在はコロナウイルス感染拡大防止のためオンラインにて実施しています。

今回は「2022年に頑張ったこと」をテーマに、専門的な技術面のことから、誰でも仕事に生かせることまで、総勢7名のエンジニアメンバーにお話いただきました。

検索処理高速化における「実験」の重要性

■登壇者プロフィール

坂本 昂輝（さかもと こうき）：バックエンドエンジニア。大阪大学大学院情報科学研究科修士課程修了。学生時代は脳科学に関連するネットワーク研究を行いつつ、深層学習を用いた音声認識システムの研究開発を行う。2018年8月にGIGに入社。

坂本：
私が2022年一番頑張ったことは、「Workshipの検索処理の高速化」です。

坂本：
Workshipでは、企業側とフリーランス側がお互いに「気になる」を送り合い、マッチングを目指します。そして「気になる」を送る相手を探すために、候補の検索機能があります。

以前まではこの検索処理に5秒かかっていましたが、現時点では0.5秒にまで短縮しました。この検索処理高速化プロジェクトを進めるなかで最も感じたこととしては「早くしたいなら実験しなさい」ということです。

坂本：
実験してみないことには、その仮説が正しいのか、間違ってるのかもわかりません。場合によっては、良かれと思ってやったことが、まったくの逆効果になることもあります。そのため、まずは実験して統計をとり比較する。この動きが必要不可欠です。

坂本：
たとえばユーザーの取得に関しては、まずユーザーテーブルに対してプロフィールとスキルについて付与して、条件は「ユーザーのステータスをアクティブにすること」としました。並び替えについては、プロフィールの更新日時と配信順で実行される形になっています。

これに対し、理論的にはインデックスを貼ると高速化するはずです。プロフィールやスキルは、ユーザーIDに対してインデックスを貼ることが必須になりますし、ユーザーのステータスにもインデックスを貼れば、さらに速くなるんじゃないかと。

最後に、実験的高速化についてです。ここでは、『Skills』を一気に持ってきています。ネットワークの状況が良いのであれば、ループ処理のなかで個別に取得すると速いケースがあります。またメモリの状況に余裕がないのであれば、小分けにして100件ずつ表示することで、速度が上がることもあります。

こういった動的な状況も考えなければいけないため、実験は開発環境だけでなく本番環境でも実施しましょう。

坂本：
まだまだ検索処理高速化のアイデアはあるので、今後も実験を繰り返しながら導入を進めていきます。

ソフトウェアアーキテクチャの真実

■登壇者プロフィール

庄子 肇（しょうじ はじめ）：バックエンドエンジニア。宮城大学事業構想学部デザイン情報学科を卒業後、ベンチャー企業でエンジニアとして常駐先のシステム開発やサイト制作の経験を積んだのち、2019年10月にGIGにジョイン。

庄子：
早速ですが、こちらのツイートをご覧ください。

庄子：
こちらはGitHubの元CTOのツイートです。この規模の会社のCTOが「最大のミス」とまで言い切ったことが個人的に衝撃でした。

ここから本題ですが、まず「良いソフトやアーキテクチャ」なんてものはありません。これらはすべてトレードオフなので、最悪じゃないアーキテクチャを選ぶことが大切です。

そのために必要な観点が「アーキテクチャ特性」です。そして、このアーキテクチャ特性をどうしていくのかを定めることを、「アーキテクチャ決定」と言います。

庄子：
ここで重要なのが、このアーキテクチャ特性を決定したうえで、それを保守することです。保守していくためにやるべきことを、アーキテクチャレディションレコードと言います。

庄子：
これを簡単に言うと、どうしてこのアーキテクチャ構造になったのかを、ドキュメントなどに残し、アーキテクチャを保守していくことです。

最後に今回のまとめです。

庄子：
また、今回はこちらの本の内容を参考にしていますので、気になる方はぜひ読んでみてください。

CSSを使って画像を描画する

■登壇者プロフィール

董 子才（とう しさい）：フロントエンドエンジニア。2016年に中国から来日して、東京の日本語学校で二年間日本語などの勉強をして、京都工芸繊維大学に入学した。2022年に新卒でGIGに入社。現在はLeadrid事業部にて「LeadGrid」とデザインシステムの開発を担当している。

董：
私は、ボタンの色やテキストのサイズなど、いろいろな要素のスタイルを決定するためにCSSを利用しています。なかでも普段から使っているのは「box-shadow」と呼ばれるプロパティです。

董：
上記のように、フレームの周囲にシャドウ効果を追加でき、またカンマで区切ると、複数の効果を追加できます。

下記にbox-shadowでできることをまとめました。

董：
画像はピクセルと呼ばれる小さい正方形の集合体です。そのためbox-shadowで小さな正方形を描く作業を繰り返すことで、画像の描画ができます。

董：
最終的な効果はこちらですね。こちらのコードはbox-shadowで書かれています。

続いてコードタイムです。

董：
ここが今回の流れです。

アップロードした画像をcanvasで描いて、getImageDataですべてのピクセル情報を取得します。そして座標と色の情報をスタイルに変換して付与する流れになります。

董：
こちらが最終的なデータの中身になります。

董：
今回の内容でわからないことがあれば、こちら（mdn web docs）から情報を確認できます。

最後に一言だけ。CSSって本当に面白いです！

PHPカンファレンスにスタッフとして参加した話

■登壇者プロフィール

石倉 彰悟（いしくら しょうご）：Workship事業部 部長。ソーシャルゲーム開発を行うSAPでカスタマーサポートとして従事した後にエンジニアに転身し、大規模決済システムやEC系Webサービス等の構築を経験。2018年にGIGにジョイン。

石倉：

2022年、個人的に頑張ったこととして、初めてPHPカンファレンスにスタッフとして参加してきました！ これまで何度か参加したことはあったんですが、スタッフ側になったのは今回が初めてでした。とても良い経験ができたので、皆さんにも共有させていただきます！

石倉：
PHPカンファレンスは、今年23回目を迎える歴史あるカンファレンス。PHPのユーザーが有志で集まって、毎年夏や秋頃に開催されています。国内でも最大規模のPHPのカンファレンスで、今年は開催2日間で1705人が参加しました。

スタッフ参加の流れは以下の通りです。

石倉：
かなりラフに募集していて結構驚いたんですが、とくにこれまでの経験などは関係なく、興味があれば誰でもスタッフ参加ができるようでした。

応募してから開催までの1ヶ月間は、毎週1回MTGがあり、各種準備を進めていく流れでした。合計で20名ほどがスタッフとして参加していました。

石倉：
スタッフとしての仕事は前日準備と、当日の運営業務がそれぞれ割り振られる形でした。ノベルティは1705人分用意するので、10人がかりで5時間くらいかかりましたね。

カンファレンス当日、僕はトラック4という部屋の司会を任されることになり、めちゃくちゃ緊張しました。それでも各部屋に経験のあるスタッフが配置されていたので、僕もフォローしてもらいながら、無事に役目を果たせました！

石倉：
今回が初めてのスタッフ参加だったんですが、一般参加したときより必死でセッションを聞いていたので、頭に残りました。あとスタッフ参加してる人はみんな、とにかくモチベーションが高いので、良い影響を受けられたなと思います！

いくつか記憶に残ったセッションを紹介します。

• PHPの今とこれから2022
• Modularising the Monolith / Ryuta Hamasaki
• php-srcを読んでみよう / 田実 誠

それぞれYouTubeのアーカイブで見られるようになっているので、気になる人はぜひ観てください！

既存インフラをTerraformでコード化したときの知見

■登壇者プロフィール

月岡 悠（つきおか ゆう）：DC事業本部 LeadGrid事業部 インフラエンジニア。法政大学経営学部卒業後、電話系企業で開発に従事したのち、2022年8月からGIGに参加。最近はブルアカにハマっている。

月岡：
私はリード獲得に特化したCMS『LeadGrid』のインフラ開発を担当しています。まずLeadGridのインフラがどうなっているのかについて、簡単に紹介します。

月岡：
基本的な構成は上記のとおり。いくつかの課題を抱えているのがこれまでのLeadGridでした。そしてこれらの課題を解決するために、『Terraform』というツールを活用することになりました。

月岡：
Terraformは、Hashicorp社がGoで開発しているマルチクラウドコンプライアント&マネジメントフレームワーク。コードでインフラの管理ができます。HCLという言語で記述を行いますが、バージョンごとの変化が激しい言語なので、バージョン管理が必須になります。

管理方法の流れは、terraform plan→terraform applyと進み、構文が解読され、実行可能であればインフラが作成される流れです。これには以下のようなメリットが挙げられます。

• IaCによってコミュニケーションコストの低下
• レビューが出来る
• コメントが残せる
• 再現性がある

月岡：
ざっくりですが、上記のような構文になります。また『Terraform Cloud』と呼ばれるものも活用しています。

月岡：
Terraform CloudもHashicorp社が提供しているサービスで、Terraform上で、何がどういった状況なのか、どう使われているのかが、すべて見えるようになっていて便利です。

既存リソースをimportする場合は、「Terraform→import」と選択して、実際にあるインフラのリソースを指定すると、tfstateファイルに落とし込めます。

月岡：
最後に、私が感じたTerraformの良い点を紹介します。

月岡：
手作業でコンソールから作るとすごく便利ではあるんですが、その分背後に何が動いているかを気にせずに作ってしまいます。そのため、それを管理したりチューニングしたりするのが大変です。

Terraformを活用すると、すべての利用リソースをコード化する必要があるため、大変ではあります。ですが、理解や把握不足によってチューニングしなくなるよりも、把握したいリソースを最初からコードで管理しておくことで、状況が把握できるようになり、最終的には自分が楽になるなと思いました。

意識で変わるコミュニケーション

■登壇者プロフィール

井田 裕也（いだ ゆうや）：Workship事業部 開発チーム マネージャー兼フロントエンドエンジニア。未経験から独学でフロントエンドエンジニアに転身。複数社での受託開発をメインに経験を積み、2019年7月にGIGへジョイン。 何を作るかよりも誰と作るかを大切に業務へ励んでいる。

井田：
今回は、エンジニアとしては斜めの切り口になりますが、「意識で変わるコミュニケーション」をテーマにお話します。

最近はテレビCMでも「未経験からでもエンジニアになれる！」などと言われるようになっていて、どんどんエンジニア戦国時代が進んできているなと思います。こういった状況で勝ち抜いていくためには、技術だけではなくて、コミュニケーションがすごく重要な要素になってきます。

そこで私が今年、コミュニケーションを活性化させるために意識して取り組んだフローがこちらです。

井田：
そして、この各フローの裏側に、とある重要な要素をとくに徹底しました。それが「聴き出すこと」です。

井田：
つまり、「話題を聴くこと」に対して「相手が共感してほしいポイントや自分が共感できるポイントを聴く」。そして「それから推測されるポイントを聴く」。これをループすることが、コミュニケーションにおいては必須だと実感しました。

井田：
コミュニケーションは、あくまで双方向で行うことなので、自分だけを主張しても成立しません。キャッチボールに例えられることも多いですが、相互理解を深めるためには、相手から聴き出すことを意識してみましょう！

OSのメモリ管理を実装してみる

■登壇者プロフィール

内園 潤也（うちぞの じゅんや）：LeadGrid事業部 バックエンドエンジニア。立命館大学卒業後、新卒としてGIGに入社。 ゲーム、ラブライブ！が好き

内園：
今年は、1からOSのメモリ管理を作成しました。

内園：
メモリ管理とは、メモリ領域の確保と解放によって、コンピューターのメモリを管理することを指します。

アプリやファイルを起動するためには、その大きさ分のメモリ領域が必要になります。そして、アプリを閉じた場合は、そこで使用されていたメモリを、再利用するために解放する必要があります。メモリは有限なので、枯渇してしまわないよう、解放する作業が必要です。

内園：
今回使った構成はこういった形です。『EDK2』は、UEFIアプリケーションを作るためのツールキットのようなものですね。全体の流れは以下のとおり。

内園：
まずUEFIの起動について。UEFIは、フォームウェアとOSの通信仕様を定めたインターフェースのことです。PCの電源を入れれば起動します。

内園：
UEFIアプリケーションは、ファームウェアが実行してくれるプログラムのこと。x86_64の環境だったら、X64EFYに配置すれば、ブートローダとみなされて実行されます。

こういった形で、OSを介さずにプログラムを実行する手法を「ベアメタルプログラミング」と言います。OCを介さないので、エラー通知が来ないために、やりづらかったですね。

内園：
続いて、boot loaderの起動です。boot loaderは、OSをストレージからメインメモリに読み込ませて、OSを実行させるためのソフトウェアです。そして、以下がKernelを実行している様子です。

内園：
メモリマップは、メモリの場所がどんな用途で使われているのかを示すものです。

内園：
メモリマップは、メインメモリの未使用領域を把握するためのものです。空き領域を把握していないと、そもそもメモリ管理はできません。

内園：
今回は、ビットマップ方式を使用し、メモリ管理を行いました。メモリのページフレームにつき1bitを使用して管理する。つまり、領域が使用中の場合は1、未使用の場合は0として管理することにしました。具体的なイメージは以下のとおりです。

内園：
今回の勉強は、抽象化された部分をほんの少しだけ覗けた気がして、面白かったです。まだまだわからないことだらけなので、勉強していきたいと思います！

GIGではGood is goodなチームを築ける仲間を募集しています！

今回の勉強会では、エンジニアとしてのスキル、業務に関することはもちろん、社外での活躍やエンジニア戦国時代を勝ち抜くための術まで、7名それぞれの2022年の総決算をお話しいただきました！

現在、GIGでは「一緒に学びながら成長していきたい！」と意欲のある仲間を募集しています。興味のある方は下のボタンからお気軽にご連絡ください！

（この記事はGIG BLOGからの転載です）