コミックマーケット(略称:コミケ)のシステムを支えるエンジニアたちの物語 ~後編~


取材対象が 1 人増えた

まえがき

コミックマーケットは年に 2 回開催される世界最大級のイベント。2012 年にマシン リソースを素早く増減できるクラウド、Microsoft Azureの採用を行いました (記事: [導入事例] コミケ Web カタログ)。

その後、C83 から C89 にかけて、計 6 回のイベント開催を経験。果たしてクラウド化は本当に効果があったのか、サービス開発・運用を担当する有限会社サークルドットエムエス 開発統括 堀口 政史 氏 (写真左)、技術統括 田邊 浩靖 氏 (写真中央)、取締役社長 佐藤 一毅 氏 (写真右) に、さらにエバンジェリスト戸倉も参加。
後半のインタビューをお届けします。

前編に続き、今回も聞き手はマイクロソフトの増渕です。

インタビュー

戸倉: さあ、みなさん。気を取り直してインタビューを再開しましょう! ではシステムについて聞いちゃいますよ♪

増渕: 戸倉さん、楽しそうですねぇ・・・・・・。もう、聞き手戸倉彩で僕いらないような気がしてますが。

佐藤: まぁまぁ、みんなで楽しくやりましょう (笑)

堀口: じゃ、再開しますね (笑)。コミケのシステムは、『サークルポータル』、『コミケWebカタログ』、『出展申し込みシステム』、『コミケコスプレコミュニティ』の4つあるわけですが、基本的にはほぼすべて Azure 化を完了しました。

田邊: システム設計の概要をお話しすると、C83 の時に作った『コミケWebカタログ』だけがクラウド サービスで、あとは WebApps です。データベースはすべて SQL Database。仮想マシンは管理用にちょこちょこ立ててますが、サービス用はすべて PaaS でできてます。バックオフィスは、たとえば RedMine を動かすための FreeBSD インスタンスとかあります。OEM で全国の中小規模の即売会にもシステムを貸しているので、ドメインは本当にたくさん動いているのですが、そういうときは PaaS は楽ですね。WebApps になったらスタンダード プランの中に、いくつでもシステムを同居できるのでテスト環境や検証環境は止めずに1台に詰め込んで安く運用しています。

増渕: クラウド化して最もよかったことはやはり、コミケのピーク対応ですよね。年に 2 回、夏コミと冬コミの時期に合わせてインフラを増強してそれ以外の時期はインフラを縮小させる、クラウドのスケールアウトと相性ばっちりです。

田邊: その通りですね。ほかにもいろいろありますよ。逆にクラウドなりの注意点やディメリットもありますが、そういうのもしゃべってもいいですか?

戸倉: え!?  そこもしゃべっちゃいますか?

田邊: せっかくなのでざっくばらんにお伝えしないと (笑)。Azure が PaaS しかなかったとき、クラウドサービス中心のときはインフラが変わったりサービスが終了したりしたこともあって当時はこのままクラウド使ってていいのかなと疑問に思うこともありました。たとえば、共有キャッシュや初代 CDN などはサービスなくなっちゃいましたし、SQL DataSync サービスなんかも、途中でサービスが終了するということで、自前で組みなおしました。

戸倉: あああー、ありましたね (汗)。.NETフレームワークでSync Frameworkに作り替える必要がありましたが、その後も開発チームは同期処理に関しては開発と進化を続けています。

堀口: PaaS のサービスはうつろいがあるというか、進化する分、いくつかのサービスが終了するリスクがありますからね。SQL Database もちょっと高くなっちゃったし。

戸倉: たーしかにー・・・・・・。プランあげるとちょっと高いですねぇ (汗)

増渕: SQL Database のコストを下げるために、Redis Service などは使っていますか?

堀口: いえ、Redis はそんなに積極的には。というのも、コミケの情報はわりと Blob ストレージに、出したい情報を出しているので、うまく Web サーバーや DB サーバーの負荷を逃がせるような設計になっているんです。

田邊: 昔はアクセスのたびにデータベースのいろいろなテーブルを参照していましたが、いまは情報を JSON にしてストレージに格納しておくことでデータベースへのクエリを減らしています。クライアントも Web ブラウザだけでなく、iOS、Android と多種多様になってきたので、JSONでサーバーの外に置いておくと便利です。ユーザーのお気に入り情報など、永続化するけど最新情報が求められるところにはもちろん Redis を検討中で・・・・・・。

戸倉: Azure にしてよかったところも聞きたいです!  (必死)

一同: 爆笑

田邊: SQL Database は、昔が安すぎたんじゃないでしょうか (笑)

SQL Azure (昔の SQL Database)最大容量

料金(ドル/月)

料金 (円/月)
Web Edition 1 GB 9.99 ドル 979.02 円
Business Edition 10 GB 99.99ドル 9799.02 円

堀口: 今は、SQL Database はシェア型から占有型に変わり、機能的にもだいぶ進化しましたね。エンタープライズレベルの機能が標準的に実装されましたし、レプリケーション機能がとっても便利です。性能プランを変えれるのも便利です。

田邊: まず、Azure というより、SQL Server ありきで僕らは技術を決めてきました。SQL Server Management Studio (SSMS) はとっても便利。 Azure 上に SQL DB を簡単に作ったり、データ検証のために気軽にデータベースを立ち上げたり、削除したりできるのですごく助かっています。

増渕: 2012 年の開発当初は、MVC と Entity Framework を使っていましたが、いまも変わらずですよね。

田邊: はい。昔 ClasicなASP.NET から、.NET MVC に行くか、Rubyに行くか、悩んだんですけど、.NET MVC を選択してよかったと思っています。 Entity Framework もリレーショナル モデルとオブジェクト指向モデルは異なる思想を持った概念ですので、それらを統合的に扱えるモデルで気に入っています。あと僕らは SQL Server ありきで物事を考えていたので。

増渕: いまもそうですか? ぜひ若い Web エンジニアに SQL Server をお勧めするポイントを教えてください

田邊: いまはそんなに製品にこだわらなくてもいいんじゃないかな

一同:  お勧めしてない(爆笑)

堀口: 僕がとお勧めポイント話しましょう。 SQL Server Management Studio (SSMS) はすごくいいですね。Web 運用ってデータ調査が頻繁にはいるじゃないですか。データをちょっと調べたいときなんかに使っています。Azure になってからは、データベースをコピーして調査して、作業が終わったら削除したり・・・・・・。

田邊: それさっき言いましたよ(笑)。でも軽に過去の静止点にもどったりできるのはいいですね!

RestoreDroppedDB2
増渕: 今は、運用の中心は Visual Studio と WebApps みたいですね。自動ビルドや自動テストなどはどのくらい取り入れているのでしょうか?

田邊: 実は自動化はほとんど自分たちでは検討していないんです。クラウドサービスや WebApps には本番とステージングを瞬時にスワップさせる機能があるので、Visual Studio からステージング環境までのリリース作業をスクリプトで自動化してます。あとは本番への切り替えについては Azure の機能に依存した運用にしています。

[スワップ] ボタン

増渕: ということは、よく弊社の資料に出てくる WebApps の GIT の連携の仕組みは使っていないですね。コードリポジトリの連携は独自実装ですか?

田邊: はい、Visual Studio の Deploy の仕組みと同じようなステップで、API を叩いています。独自に作った理由ですが、Azure のアプリ環境が、クラウド サービスだろうと、WebApps だろうと使えるという利点があるかなとおもいまして。インフラ面はかなり Azure さんに依存してますけどコード管理は配布まわりは自由にしたいなと。あと、極端な話、スワップ機能 をあきらめれば Azure から オンプレにも移行できますよ。

増渕: なるほど。WebApps はブルーグリーン運用を手軽に構築できる Swap 機能と、スケールアウト機能のみ使っていると。アプリは .NET MVC をベースにしていますが、運用とか、技術者の採用面ではいかがでしょうか。

堀口: 今まさに人を探しているので、これを読んでいる C# エンジニアさん、もしコミケのお仕事にご興味があればぜひご連絡ください (笑)

増渕: C# エンジニアさん、コミケのお仕事ができるチャンスみたいですよー。

田邊: C# ができる人、かつ、Web サービス開発経験者、という条件で採用を行うと、正直探すのはとっても大変です。マイクロソフトさんにはもっとエバンジェリスト活動頑張ってほしい笑。ですが、僕らは 軽量プログラム言語 系の技術で探すよりも、中長期的に見て品質が担保できると思うんです。言語の特性だけじゃなく、エンジニアの質としても。もちろん PHP にも Ruby にも素晴らしい技術者はたくさんいるんですが、わりと習得しやすいというのもあるので、個々のエンジニアレベルのばらつきが激しい印象です。

堀口: あとあんまり技術的な理由じゃないのですが、.NET C# と SQL Database は、日本語で開発できるので、可読性が高いというのもいいですね。テーブル名とか無理に変なローマ字や英語とか使いたくないですし。

田邊: コミケってすごく特殊なアプリで、データ項目名やクラス名に英語にない単語とかもありますからね。

増渕: ほお、なるほどー。それは気が付きませんでした。可読性が向上して、スポットで入るエンジニアさんへの説明などは楽ですね。

今後に向けて

増渕: では、ゲストの戸倉さんも含めて、これからのコミケをこうしたい。技術でこんな風に盛り上げていきたい、という所信表明をお願いします。

戸倉: コミケの Wiki みたいなものをみんなで一緒に作っていきたいですね。単なる Wiki になるかどうかはわかりませんが、コミケはコンシューマーが作るイベントですから、コンテンツはみんなで作っていきたい。アイディアもみんなで考えていきたいと思います。物理の世界だと、「コミケかるた」、みたいなものでもいいし、初めて行く人でも怖くないよーというのを作ってみたいです。個人でもやってみたい。

佐藤: コミケ検定、みたいなのを妄想していたりします。僕もコンシューマー ジェネレーテッドがコミケの運営精神だとおもうのですが、ある程度の規律も必要だし、事故の内容にするために、ボランティア側の人たちがこんなのいいよ、みたいな経験値を共有しあってくれるとうれしいですね。

堀口: 僕は規範ではなく、コンテンツに注目してまして、もっといろんな情報をつないでみたいですね。すべてを把握している人がいないし不可能かもしれないですけど。

田邊: Hololens が安くなったら、VR とかやってみたいです。初めはウィザードリィみたいに線画で、サークルカットなどの情報が徐々に埋まっていくようなやつ

増渕: それは楽しそう。アーカイブもできますし、地球の裏側の人にコミケのバーチャル空間を提供できるのはワクワクしますね。では、このあたりでコミケを支えるエンジニアインタビューはおしまいにします。みなさん長い時間ありがとうございました。(888888)