この記事は新歓ブログリレー2022 24日目の記事です。
こんにちは、19Bの@temmaです。
普段は、部内サービスの開発・運用をしているSysAd班というところで活動しています。
昨年、一昨年と書かれたSysAd班の振り返り記事を今年度も書いて行こうと思います。
to-hutohu
temma
2020年度の振り返り
2019年度: 3~2年前。この年度末で@to-hutohuが引退。
2020年度: 2~1年前。@temma, @sappi_redをリーダーとした新体制初めての年。
2021年度: 1年前~現在。この記事で振り返る年度。
2年前の2020年度は @to-hutohu, @takashi_trap から @temma, @sappi_red に本格的にリーダーを移行して、初めての年でした。
この一年は「はずみ車を回し続けること」をテーマにメンバー育成・仕組み化・ドキュメント化の3つを推し進めました。その結果、開発環境の充実やメンバーの増加に伴って、よりチームらしい活動ができるようになりましたが、プロジェクトリーダーの負担増加や活動に対するインセンティブの問題などは依然として悩みのままでした。
昨年から継続したこと
そういった悩みに対して手探りではあったものの、継続した取り組みもあります。
メンバー育成
QSoCやWebエンジニアになろう講習会は部内でも好評で、今年は@hijiki51主導で実施しました。
temma
アウトプット
ISUCONやICTSCといった大会への積極的な参加や技術書店など各種イベントでの発表、技術ブログ「SysAdTechBlog」の連載など継続的なアウトプットを通して、SysAd班の技術力/知名度向上とテクニカルライティングスキル向上を図りました。
その甲斐あってか、今年開催されたISUCON11ではtraPとして作問チームに招待していただくなど、貴重な機会を頂くことができました。
メンバーからも「インターン先でtraPの話題が出た！」というようなエピソードを聞くことが多くなり、嬉しい限りです。
2021年度SysAd班の実績
- ISUCON11
- 作問
- 1チーム本選出場
- ICTSC 2021 冬の陣
- 3位
- mixi Bug Shooting Challenge
- 優勝
2021年度を振り返る
さて、こういった活動を継続していく中で新たにどのような取り組みを行ったか振り返ります。
2020年度の振り返りを書いた2週間後には、2021年度一回目となるSysAd班集会を行いました。そこで「開発から保守へ」を2021年度の方針として提案しました。2015年のtraP設立からこれまで多くのアプリケーションがスクラップアンドビルドを繰り返し改善されてきました。その数は大小合わせて20を超えます。
特に部員向けの主要サービスである7つのアプリケーションを筆頭にtraQ-RやtraQ-S、booQ v2などがフルスクラッチで書き直されてきたわけですが、今年度からは保守を念頭においた開発スタイルに焦点を当てました。
これには以下のような背景があります。
- これまでの開発
- 手探りで作ったプロジェクトが多かった
- 既存コードの拡張性を考えるとフルスクラッチするのが妥当だった
- 現状（2021年度初頭）
- traQなどを参考にした良い設計のプロジェクトが増えてきた
- 各プロジェクトで同じようなコードを書く機会が増えた
- これからの開発
- フルスクラッチを選ぶ必要性が減った
- 車輪の再発明ではなく、本質的な機能開発に注力できる
SysAd班デザイン部の設立
これまでの開発では、各プロジェクト内でそれぞれがUIデザインを行っていました。
そのため、各サービスでデザイン的な統一が取れていない状況でした。また、UIデザインに関する知見の共有や相談が班というコンテキストで行われないため、班としての利点を活かしきれていませんでした。
このような状況を改善するため、UIデザインに優れたアドバイザー集団としてのSysAd班デザイン部を設立しました。アドバイザーにとどめたのは、デザイン的な統一を図る一方で各プロジェクトのオリジナリティを維持したかったためです。基本的には各プロジェクト内の意向に委ね、配色や複雑なコンポーネントのデザインなどについて適宜相談・依頼する形を採用しました。
デザインがネックで後回しにされていたissueが解決されるなど、とても積極的に活動してくれています。
週間報告書
週報は2020年度に始めた取り組みです。
開発の過程を残すことでプロジェクト間で活動を共有するとともに、ドキュメントに残らない情報をすくい上げるものとして週間報告を書くようしました。
2021/4/1時点で2019/10/20から一年以上の報告書が書かれていたわけですが、何より面倒ということもあり徐々に更新頻度が低下していました。
一方、書きっぱなしでフィードバックが行われていなかったため、更新頻度も落ちてきていました。
2021年度は積極的にフィードバックを返す機会にしていければと思います。
また、上のような理由もかなり大きな要因だったと考えています。
2021年度は週間報告書の目的を見直し「週の進捗を振り返り、プロジェクトリーダーとのコミュニケーションのきっかけとする」の一点に絞りました。
これは、「プロジェクトの進捗が小さいのはプロジェクトリーダーがうまく回っていないからであって、プロジェクトリーダーに呼びかけの負担がある以前までの形では解決しないのではないか」と言う反省があったためです。
そのため、記録場所をwikiからtraQに移動し、リマインドもBotで行うようにしました。
当時はこれでうまくいくように思えたのですが、進捗量が小さいという状況はあまり改善しませんでした。これは、ずっと悩んでいた問題で「インセンティブが小さいのではないか」「各リーダーのマネージャーとしての働きが良くないのか」「そもそもなぜ自分たちは進捗できたのか」などいろいろ考えていました。
結論が出たわけではありませんが「オンラインでの活動にシフトした結果、細かな交流の機会が失われたため、メンバー間での関係性がうまく進展しなかったのではないか。また、関係性が進展するまでの期間で進捗量が小さい状態が常態化した。」というのが現状の見解です。また、この状況を解決するためには絶対的にコミュニケーション量が必要であるということも感じられたので、夏頃からは、各プロジェクトで定期的な集会を行うようにしました。
劇的に改善したわけではありませんでしたが、後述の引き継ぎもあってか積極的に話に加わったり、タスクをとったりする場面が増えてきたように思います。何より、プロジェクトメンバー同士でのぎこちなさが薄れ、フランクな会話を交わせるようになったことが嬉しいです。
引き継ぎ
@temmaと@sappi_redの進路状況や引き継ぎ期間も踏まえて、2021年の6月頃にリーダーを募集しました。ここで、マネジメントリーダー補佐として@xxarupakaxxが、テクニカルリーダー補佐として@hijiki51が就任してくれました。二人とも大学に入ってからプログラミングを始めたにもかかわらず、すでにSysAd班を支えるリーダーとして活躍してくれました。
その後、感染が広がる中でオフラインでの活動が制限された難しい状況ではありましたが、2021年10月に正式リーダー職を引き継ぎました。色々悩んだと思いますが、引き継ぐと言ってくれて本当に嬉しかったです。応援しています！
SysAd班の運用するインフラ
ここまであまり技術的な話はありませんでしたが、もちろん主な活動は技術的なことが多いです。2019年に公開されたSysAdTechBookで紹介して以来、traPで運用しているサービスのインフラについて、その全体像を紹介する機会がなかったのでこの記事で紹介します。
概要
ConoHaのVPS(Ubuntu20.04LTS)を使用しています。
Develop用のm011(1GB)が1台とProduction用のh101(4GB, Arch Linux), s323(1GB), w423(1GB), s512(1GB), w933(1GB)があります。
ちなみに各インスタンスには東工大の教室名に因んだ名前がつけられています。
監視用のlibra(2GB)とDB用のkmbk(2GB)も同様です。
また、各アプリケーション用サーバーとlibra・kmbkはプライベートネットワークで接続されています。
各サーバーに対するSSH接続時の認証にはlibnss-jsonを使用しています。詳しくは以前のブログの「libnss-jsonとは？」の項を御覧ください。
アプリケーション用サーバー
(h101を除く)Production用のアプリケーションサーバーは共通して以下のような構成をしており、外からのアクセスはWebサーバーであるCaddyによって、各サービスのコンテナに割り振られます。同様に、各サービスのフロントエンドもビルド済みのものがCaddyから静的配信されます。
また、サーバーやコンテナのメトリクスを取得するためnode_exporterやcAdvisorが起動しています。
これらのアプリケーションはすべてコンテナとしてデプロイされており、サービスごとにDocker Composeで管理されます。また、DockerのLogging driverにはdocker-loki-pluginが存在するので、これを用いて各サービスのログをlibraのLokiにpushしています。
Database
データベース用のサーバーは以下のとおりで、監視とロギングについてアプリケーション用サーバーと同様です。本番環境と開発環境の2つのDBが存在し、Adminerからアクセスできます。
DBのデータは毎日4時にGCPのCloudStorageにバックアップされ、3世代分が保持されます。
監視
libraからサーバーやサービスの状態をPrometheusで監視し、Grafanaで可視化しています。
外形監視や各種リソースの情報を取得するために各種exporterを使用しています。
これらのリソースに異常があったときは、GrafanaのAlertからtraQに通知されるため、早期に対応することが可能です。
CI/CD
traPのサービスのほとんどはGitHub上で管理されており、GitHub Actionsを用いることが可能です。それぞれのサービスでLinterの実行やテストのカバレッジ検出などを行っていますが、ここではCDに注目して紹介します。
SysAd班ではGitHub Flowを採用しており、ほとんどのサービスではPRがmainブランチにmergeされたタイミングでバンドル後のクライアントやdockerイメージがビルドされます。この内、ビルドされたイメージはGitHub Container RegistryにPushされます。後は、これらの内容に更新すれば良いです。
SysAd班には、ChatOpsを可能にするDevOpsBotがtraQに存在し、以下のように特定のコマンドを実行することができます。
DevOpsBotの詳細については、過去のブログを参考にして頂けると良いですが、Bot経由で各サーバー上に予め登録されている以下のようなシェルスクリプトを実行することで先程ghcrにプッシュされた最新のイメージに差し替えることが可能です。
booQの例
#!/bin/bash
set -eux
container=$1
cd /srv/booq
sudo docker-compose pull ${container}
sudo docker-compose up -d --no-deps --build ${container}
knoQの例
#!/bin/bash
set -eux
repo=$1
cd /srv/knoq
if [ "$repo" = "server" ]; then
sudo docker-compose pull
sudo docker-compose up -d --no-deps --build knoq
elif [ "$repo" = "ui" ]; then
sudo curl -L -Ss https://github.com/traPtitech/knoQ-UI/releases/latest/download/dist.tar.gz | sudo tar zxv -C ./web/
fi
以上の仕組みによって、新しくプロジェクトに参加したメンバーでも、コードをプッシュしtraQ上でコマンドを打てば、複雑なインフラ環境を意識することなく変更を反映することが可能になります。
この他にも、mainの状態がGitHub Actions経由で開発環境に自動でデプロイされるようになっているサービスも存在します。詳しくは以下を御覧ください。
traPtitech加えて、これらの環境はansibleで管理されているため、サーバーさえあればいつでも立ち上げることが可能です。
認証認可
最後に、少しインフラから離れてtraP内でのSSOについて紹介します。
traPではSSOの実現には主に2つの方法が用いられています。
一つ目は、traQがOpenID Providerとして機能するパターンです。主に内製サービスの認証認可に使っています。
もう一つは、pipelineと呼ばれるサービスがtraQへのログイン状態を確かめてJWTを付与する方法です。サービス側でJWTの正当性を検証することで認証を行います。検証部分はCaddyのpluginとして実装してあったり、利用しているOSSを拡張していたりします。
traPtitech最後に
ここまで読んでいただいてありがとうございます！
SysAd班は新リーダーのもと2022年度も活躍します！！乞うご期待！！！
もし少しでも、SysAd班の活動に興味を持った新入生がいたら、ぜひ新歓のイベントで実際に体験してみてください！
皆さんの入部をお待ちしています！！！
