Classiの現状を技術的に分析してみた

Classiといえば先日,不正アクセスにより個人情報が流出したことを発表したサービスだ.

国内高校の半数が利用するClassiの不正アクセスについてまとめてみた – piyolog

そんなClassiがユーザ数の増加に伴い,サービスの動作が不安定な状況にある.Twitter上では #Classiを許すな というハッシュタグが生まれユーザのサービスへの改善を求めるツイートがみられる.

現状の原因

Classiがサービスを利用する教育機関へ配信したお知らせから,状況が分かってきた.

<原因>
大きく以下の2つが複合的に作用して接続不良という結果につながったと分析しております。

■原因1:アクセス増加と集中
Classiは、2020年2月時点と比較しユーザー数でおよそ3倍、アクセス数でおよそ7倍のアクセスをいただいています(2020年5月8日時点の調査)。その結果、データの処理量がClassiで取り扱うデータを格納しているデータベース・サーバーの当初の想定を超えてしまい、サービスに繋がりにくくなっている状況が発生しています。

この件に関しては、全て弊社の想定の甘さが招いたことであり、生徒の皆さまをはじめ、ご利用いただいているユーザーの皆さまにご迷惑をおかけしています。

■原因2:システムの問題
詳細な調査の結果、原因1であげられたデータベース・サーバー側だけの原因ではなく、Classiの機能を提供しているアプリケーション・サーバー側にも問題がある可能性が高いことが認められました。

今までClassiの提供してきた様々な機能を形作っている部品の中に、前述のアクセス増加の影響を受けて問題を起こすものが、大小様々なかたちで混ざっていることがわかっており、継続的に調査を進めてまいります。

Classiにつながりにくい状況について – 島根県立隠岐島前高等学校

上記の情報によるとつながりにくい状況の原因は,大別すると2つの原因があるという.1つ目はアクセスの増加と集中だという.2つ目はシステムの問題だという.

(1) アクセスの増加

教育機関のトラフィックは授業開始時間に急激に集中する性質をもつ.筆者自身も,小学校のコンピュータ教室で授業開始と同時に一斉にActive Directory管理のマシンへログインしたところ,長時間またされた経験がある.

Classiは一部の機能をCOVID-19による休校への支援として公開した.これにより,さらにユーザ数がこれまで以上に増加した可能性がある.Classiのテックブログには,2月末の一斉休校に伴いアクセスが急増しているグラフが公開されている.ただし,軸がないためどの程度の増加は分からない.

(2) システムの問題

インフラはAWS

ClassiはインフラストラクチャにAWSを採用している.これは複数の資料から確認できる.積極的にサービスへAWSサービスを活用していることが理解できる.

AWSはパブリッククラウドである性質上,オンプレミスに比べて柔軟にスケールアウトが可能である.そのため,システム・アーキテクチャに依存するが,テナントの増加にあわせて柔軟にスケールできると考えられる.

以下の機能のバックエンドにAmazon Elasticsearch Serviceが使われているという.

  • テスト,問題,アンケートなどの検索機能(コンテンツボックス)
  • 先生と生徒がメッセージをやり取りする機能(校内グループ)

サービス全体のアーキテクチャとしては,以下が順に接続されているという.

  • Route 53
  • Elastic Load Balancing
  • Amazon EC2 (Nginx, Ruby on Rails)
  • Amazon Aurora

アプリのバックエンドはRuby on RailsとPHP

Wantedlyのブログにバックエンドの言語が書かれていた.

様々な歴史的経緯があり、現在Classiには20個近いRailsアプリがあります(マイクロサービシーズではないです…)。

この数はRailsエンジニアの人数よりも多く、各アプリの細部までエンジニアの目が届いていない状況です。

それもあってか、各アプリでそれなりの技術的負債が溜ってしまっています。

自分はその技術的負債を一つずつ一つずつ直しています。

多くはN+1潰しやindexチューニングなど基本的なパフォーマンスの問題解決が多いですが、抜本的にロジック改善をしないといけない場合もあります。

また、Railsアプリの他にPHPで書かれた部分もあり、必要とあらばそちらも改善を行っています。

改善を行ったものはできるだけ速くリリースするようにしていますが、その際には今学校で使われていることを意識し、極力授業などの妨げにならないように気をつけての作業を心掛けています。

Classiのサーバサイドの今とこれから | Classi株式会社’s Blog

以下の資料によると歴史的な経緯により14個のRailsでつくられたアプリケーションが存在するという.エンジニアの数と管理するアプリケーションの数が見合っていないらしく,技術的負債が積み重なっているという.

ClassiのRuby/Railsバージョンアップ始動物語 – Speaker Deck

改善の取り組み

<対策>
■アクセス増加と集中に対する対策
弊社が採用しているサーバーを提供しているAWS(Amazon Web Services)で最も高性能なサーバーに置換した上、台数についても技術的に可能な限り増台を行いました。

■システムの不具合に対する対策
前述の通り、可能な限りサーバーの増強を行いましたが、処理スピードを一気に改善するという結果には至りませんでした。Classiの各機能に残存する負荷要因をひとつずつ特定し、改修を行う作業を、夜間含め日々行っています。

■改善に向けた見通し
現在「データベース・サーバーとアプリケーション・サーバー接続不具合」が今回の障害の大きな原因であることを特定できております。その解決に向け、現在、サービス保守運営体制を40名に大幅増員した体制を構築し、(1)問題の分析・(2)日々の不具合の改善・(3)データベース接続に係る根本的な問題の改善の3点に取り組んでおります。現状、まだ大幅な改善は見えておりませんが、短期・中長期の両面で、改善に努めてまいります。

Classiにつながりにくい状況について – 島根県立隠岐島前高等学校

インフラストラクチャ

アクセス増加への対策として,AWS上のインスタンスのスケールアウト(台数増加)とスケールアップ(個々のマシンスペック向上)を実施したという.これによりインフラストラクチャでのリソースは十分に確保されたといえる.

アプリケーション

上記の発表によるとインフラの強化ではサービスの改善がみられなかったという.根本的な問題は14に及ぶアプリケーション側にあると考えられる.以下から現状のサービスの稼働状況が確認できる.5月2日からは夜間のメンテナンスも行われているという.

Classi Status

CRE/SRE

Classiには,SREやCREとよばれるロールが存在している.こうしたポジションのエンジニアやアプリケーションエンジニアによるサービスの改善が,今もなされていると考えられる.

終わりに

サービスClassiを調べてみたことで,Classiがパブリッククラウドを使った積極的な開発を行っていることが分かった.一方で,スタートアップでみられる歴史的な経緯に伴う技術負債に苦労していることも分かった.事例を通じて,サービスの改善には,単にインフラの強化だけでなくその上で動作するアプリケーションの特性を理解して改善することが必要だと分かった.

参考: speakerdeckのclassi関連の公開スライド

*本記事はClassiを擁護,非難する意図はありません.また,内容に誤りがあればコメントでご指摘をお願いします.

2020/05/18 19:16 技術スタックの説明を具体的に修正,タイポとスケールアウトとスケールアップの説明を修正

Log Shipperのパフォーマンス測定の結果を調べてみた

Alibaba Cloudでパフォーマンス測定の結果が出ていた.

ログ収集エージェントの評価 – FAQ| Alibaba Cloud ドキュメントセンター

Log Tailがパフォーマンスではトップらしい.LogstashはJVMで動いているせいかメモリを食いやすいそう.

1
出典:「ログ収集エージェントの評価」

fluentdのtagomorisさんがベンチマークした結果が以下にある.

fluentd のベンチマークとってみたよ! – たごもりすメモ

Xeon L3426でRAM 16GBのCentOS 5で測定したデータなので古めではある.この記事だとCPU 1コアあたり18000msg/secが限界らしい.今はもっとパフォーマンスが出そうな気がする.


卒研でこのあたりの具体的なパフォーマンスの数値を課題の裏付けに使えないかと思って調べてみた.それなりのログがこないとボトルネックは発生しないということは分かった.トランザクションが多いとボトネックになるとは思う.

ツイッターを見ていたら,よくあるやつを見つけて悲しくなった.

パーティーに行くタイミング|問題解決のPythonプログラミング 2章

書籍「問題解決のPythonプログラミング」を積んだままだったので読みながらコードを書いてみた.今回はその2章にある問題をといてみた.

(問題)有名人が参加する時間帯が事前に分かっているパーティーがある.このパーティーに1時間だけ参加するとき,最も多くの有名人がいる時間帯がいつか求める.

入力は有名人のいる時間帯をあらわすタプルで構成されている.例えば(6,8)の場合は6:00から8:00まで参加するということをあらわす.今回の場合は9:00 – 10:00が5人で最多となる.

タイムライン

簡単なコードを書いてみた.

guest_schdules = [(6,8), (6,12), (6,7), (7,8),
        (7,10), (8,9), (8,10), (9,12),
        (9,10), (10,11), (10,12), (11,12)]
times = []

for schd in guest_schdules:
    times.append(('start', schd[0]))
    times.append(('end', schd[1]))

times_sorted = sorted(times, key=lambda x: x[1])

current_guest = 0
max_time = max_value = 0
for time in times_sorted:
    if time[0] == 'start':
        current_guest += 1
    elif time[0] == 'end':
        current_guest -= 1

    if max_time < time[1]:
        max_time = time[1]
        max_value = current_guest

print("Answer:", "time=", max_time, "num_of_guest=", max_value)

実行結果:

$ python3 2-party.py
Answer: time= 9 num_of_guest= 5

WordPressをManaged Serviceに移行

これまでは,さくらのVPSを使って運用していました.自分のブログのためだけに仮想マシンのメンテナンスをするのが面倒になったのでKAGOYA JAPANのWordPress専用サーバーに移行してみました.

WordPressのコンテンツ量が多いせいか標準の移行ツールでインポートができず,最終的にはphpMyAdminでダンプしたテーブルをインポートすることで対処しました.MySQLデータベースの wp_postsテーブルとwp_postmetaテーブルをコピーして,wp-content/uploadsにメディアファイルをアップロードすれば正常に動作するようです.

KUSANAGIの速さに驚かされています.自分でチューニングや設定を行っていたことから開放される,従来よりも安い価格で運用できるので満足しています.

Creating Private Wiki by mkdocs + GitLab CI + Heroku

I was looking for private wiki written by Markdown. This post introduces how to create a private wiki by mkdocs + GitLab CI + Heroku.

mkdocs

mkdocs is simple document builder from markdown to html. Used theme is material.

mkdocs.yaml

site_name: Notebook
theme:
  name: 'material'
  language: 'ja'
extra:
  search:
    language: 'ja'

GitLab CI

Putting a config file .gitlab-ci.yaml in root path on git repository.

.gitlab-ci.yaml

build-mdfiles:
  image: python:3.7-alpine
  stage: build
  script:
    - pip install -r requirements.txt
    - mkdocs build
    # test
    - apk add git
    - git clone --depth 1 https://github.com/nulltask/heroku-static-provider.git static-site
    - cd static-site/
    - git config user.email 'koya@koyama.me'
    - git config user.name 'koya'
    - git remote add heroku https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APPNAME.git
    - git pull heroku master
    - cp -r ../site/* public/
    - git add .
    - git commit -a -m `date +deploy_%Y%M%d_%H%m%S`
    - git push heroku master

Setting secret variables on Repository.
Settings => CI/CD => Variables

GitLab Setting

Heroku

Following these steps:

  1. Create Heroku account
  2. Setup Heroku CLI ENV
  3. Create a site on Heroku
    1. heroku create
  4. Optional: If you wish to use BasicAuth, you should run theses commands.
    1. heroku config:set -a=koyawiki USER=YOUR_USER
    2. heroku config:set -a=koyawiki PASS=YOUR_PASS

On Merge Request created

Running CI
CI Console
Build Wiki