RoomClip 開発者ブログ

Yii2でブログシステムを作ってみた

Tunnelでインターンをしている松永です。
今回はこの『RoomClip開発者ブログ』を開発した話をします。

Yii2フレームワーク

タイトルにもある通り、このブログはYii2というフレームワークを用いて一から実装されています。ちなみにRoomClipの開発に使用されているのはCodeIgniterです。

Yii2はPHPのMVCフレームワークのひとつで、高速であることやセキュアであることを売りにしているようです(他のフレームワークがそうでないかというと、そんなこともないと思いますが)。 実際に使ってみると、キャッシュを簡単に使用できたりCodeceptionでのテストをサポートしていたりと非常に開発をしやすい印象を受けました。サービスの規模に応じての拡張が容易であることも魅力的でした。

このYii2にはGiiというコード生成を行うためのExtensionがあり、これを用いるとDBテーブルに紐付いたモデルクラスやCRUDコードなどをGUIを通して生成することができます。また、テーブル構造の変更を考慮してクエリなどは生成したモデルクラスを継承したクラスに記述をしています。

gii

Yii2についてのより詳細な説明はこちらを参照してください。

開発

既存のコードに変更を加えたり機能を追加することはありましたが、ほぼ何もない状態からWebアプリケーションの開発を行うのは僕にとって初めての経験でした。 知識が足りないことも多く、細かなソフトウェア設計には頭を悩まされましたが、他のエンジニアに助けてもらいつつ実装を進めていきました。

コーディング規約は基本的にYii2のコードに合わせるように定めました。Giiでコードを生成するとDBのカラム名と生成される変数名が同じになるため、カラム名もキャメルケースで統一しています。

モデルクラス内のクエリ文はできるだけcreateCommandを使用して書きたいという思いがあったのですが、そのままだと目的のクラスのオブジェクトではなく連想配列として値が返ってきてしまいます。また、数値を期待していてもクエリを通すと文字列として返ってくるため型のチェックと変換を行いたいです。

そこで、以下のようなtraitを作成し、モデルクラスに与えることでこの2つの問題を解決しました。

このコードではreadObjectで連想配列をクラスで包み、モデルクラスのValidatorを利用して型の変換を行っています。このValidatorはGiiでのコード生成時にテーブル構造から読み込まれるものなので、別途型情報を付与する必要はほぼありません。

実際に使用する際は以下のようにしています。

高速化

ある程度の形が出来上がったら、高速化をする段階に入りました。

ここではレスポンスタイムの確認にNew Relicを使用し、PHPの関数ごとにどれくらいの時間がかかっているかを見ます。どのようなクエリを何回叩いているかなども表示してくれるので、キャッシュの仕方を決めるのに非常に役に立ちました。

Yii2には、FileCache / Redis / Memcachedなどを扱うためのクラスがあらかじめ用意されており、Configで切り替えることが可能です。このConfigはすべてのアクセスの受け皿となるEntry Script内でyii\web\Applicationオブジェクトの作成時に渡されるので、このオブジェクトを通していつでもキャッシュにアクセスすることができます。この技術ブログではRedisを使用しました。

テスト

RoomClipの開発でテストを走らせることはしていなかったので、この機会にテストのコードを書くことにも挑戦をしました。テストにはCodeceptionというテストフレームワークを使用しており、これはYii2がサポートしているため簡単に導入することができました。また、Fakerというツールを使用してFixtureのためのテストケースを生成しています。
現在はcronで定時にユニットテストを走らせてSlackにログファイルをアップロードするようになっています。コミット時にフックさせられると良いかもしれません。

もちろんテストをすることでバグを発見する手助けになるわけですが、テストコードを書くこと自体も思ったより負担になりそうです。実際に運用をする際には、どれだけ手軽にテストができるかが重要になりそうですね。

完成

ざっくりではありますが、このようにして技術ブログが完成しました。
ブログシステムを一から作れることは自分にとって良い経験でしたし、メインのサービスとは切り離されているので新しいことをやるのにはとても都合の良い場でした。
これからエンジニア・デザイナー・セールス含め、多くの記事が追加されていくと思いますので、興味を持っていただけたらと思います。

今後も『RoomClip開発者ブログ』をよろしくお願いします。


この記事を書いた人:松永

Tunnel社でインターンを始めてもうすぐ1年半のB4。趣味は競技プログラミング。


RoomClipのログ収集基盤をKinesis&Lambdaを使って構築してみる

こんにちは、Tunnelでエンジニアをしている熊谷です。

気持ち安らぐログ収集基盤に向けて

サービス向上のためにログ収集はとても大切だと思いますが、RoomClipでも日々、様々なログを収集しており、今回のKinesisで取り扱ってるログだけでも30種類近くあります。

ログデータの性質として、当たり前ですがデータ量がひたすら蓄積し続け、サービス拡大やキャンペーン・広告などで流量が爆発的に増えることもあります。その都度、サーバーが停止したり、ネットワークにトラブルが起きたりして対応を迫られるのは極力避けたいものです。

RoomClipでは、ユーザー数増加、サービス拡充につれ、これまでのFluentdでのログ収集基盤では辛くなってきたため、話題奮闘中(?)のAWS Kinesis&Lambdaを取り入れた構成に変更することになりました。また構成を変更するにあたり、トラブルやデータロス無く安定的に動作することはもちろんですが、よりスケーラブルで汎用的な構成を目指しました。

先に結果を言いますと、Kinesis&Labmdaの導入により、ログを安定的に収集することができるようになり、新しいログを追加する際も簡単に安心して行うことができるようになりました。

Kinesis&Lambdaによるログ基盤の考察

Kinesisを利用したログ収集についてネットで調べてみると、基本的な構成として以下のようなフローがよく見つかると思います。

(1) td-agent -> Kinesis -> labmda -> S3

さらにログをクエリで分析するために、Redshift(or Elasticserch)にもデータを入れたいとなると以下のようなフローが見つかります。(この場合、Kinesis Firehoseを導入すれば簡単にできると思います)

(2) td-agent -> Kinesis -> labmda -> S3 -> Lambda -> Redshift (or Elasticsearch)

ただ、取り扱いたいログが1種類の場合であれば上記の構成でいいと思いますが、数十種類のログを扱う場合、ログごとに同じ構成を用意するのは非常に手間で冗長なので、どこかでルーティング処理をいれようとなると思います。その場合の構成は以下のようになります。(ルーティング処理をいれれる箇所はいくつか考えられますが、Redshift手前のLabmdaで処理する場合で考えてみます)

(3) td-agent -> Kinesis -> labmda -> S3     -> Lambda(ルーティング処理) ─> Redshift(table A)                └──> Redshift(table B)

上記の構成であればルーティング規則に則ったログをtd-agentに流し込みさえすれば、自動的にそれぞれのテーブルにデータが挿入されるようになります。

ただ問題点としては、ログ流量が多く、RedshiftへのCOPYが頻発した場合は詰まってしまいます。これらはLambdaでの処理を工夫したりBatchSizeを変更することで多少は上限を引き上げられるかもしれませんが、いずれにせよ、GZIPファイルの数だけRedshift COPY(with JSON GZIP Options)コマンドが走るため、トランザクションが重複し(テーブルロックがかかるため)、クエリ待ちが多発してしまいました。

対応策して、RedshiftのCOPY Manifestを使うような構成に変更しました。(コマンドでいうと「COPY JSON GZIP」から「COPY JSON GZIP MANIFEST」へ)。要は、ログ集約されたデータをさらにManifestで集約することで、大幅な負荷軽減&高速化をしようということです。これならば、どれだけGZIPファイルが増えても1クエリで叩けるようになります。構成は少し複雑で以下のようになりました。

(4) td-agent -> Kinesis  -> labmda1 -> S3(バッファ用Bucket)  -> Lambda2 -> S3(マニフェストファイル用Bucket) & S3(アーカイブ用Bucket)  -> Lambda3 -> Redshift

現在のRoomClipのログ収集基盤

現在、RoomClipのログ収集基盤は上記(4)の構成で運用しています。流れをもう少し詳細に説明すると以下の通り。

  1. td-agentは、ログを集約してKinesisに送信する。
  2. Lambda1は、(KinesisのPUTをトリガーとして起動し)、Kineisからログデータを取得(PULL)して、S3バッファ用バケットに保管する。
  3. Lambda2は、(定期実行により起動し)、S3バッファ用バケットにある全てのファイルをログの種類ごとにS3アーカイブ用バケットに階層化して移動させる(ルーティング処理)。同時に、ログの種類ごとにマニフェストファイルを作成してS3マニフェスト用バケットに保存する。
  4. Lambda3は、(マニフェストファイル作成(S3:PUT)をトリガーとして起動し)、Redsfhitに「COPY Manifest」を実行する。

ポイントとしては、

  1. S3ルーティング処理の切り離し
  2. Redshift用マニフェストファイルの生成

になるかと思います。

Kinesis&Lambdaを導入してみて

まだ全てのログをKinesisに移行はできておらず、これからログ流量もまだまだ増えると思いますが、それらを考慮しても、Kinesisのシャード数上限やLambdaの同時実行数の制限にもまだまだ余裕があるので、しばらくはこの構成で耐えれるのかなと思います。

この先、また新しく画期的なサービス・アーキテクチャが続々と生まれ、ログ収集の形も大きく変わる可能性は大いにありうるので、その辺の動向も追いつつキャッチアップしていけたらと思います。

また、せっかく頑張ってログ収集しても、そのログデータを活用できなければ意味がないと思いますので、ログデータ可視化〜問題発見・解決にも力を入れていき、より良いサービスへとつなげていたけらと思います。

参考サイト


この記事を書いた人:rkumagai

熊です。RoomClipのインフラ〜サーバーサイドを担当しています。