ITアーキテクト大喜利～これからのアーキテクトは何を考え行動すべきか？
午後の講演は、A・Bの2会場で同時進行された。
A会場では、日本Javaユーザグループ／日本Springユーザグループの河村嘉之氏、鈴木雄介氏による講演「ITアーキテクト大喜利～これからのアーキテクトは何を考え行動すべきか？」と題したセッションが行われた。この講演では、アーキテクチャの位置づけと3.11による変化が話された。
「アーキテクチャ」は、利害関係者の関心事をモデル化したもの
まず語られたのは、「アーキテクチャとは何か」。システムにはミッションがあり、さまざまな利害関係者がいて、それぞれ関心事がある。アーキテクチャは、ログ、プログラミング、予算、といったこれらの関心事をモデル化したものと言える。
3.11の広域災害によって、社会インフラに障害が出て、東北だけではなく、関東、そして日本全体に影響を及ぼした。このことから、「いかにシステムを継続するか？」というDR（ディザスタリカバリ）の視点に客の要望が変化した。しかしコストはかけられない。3.11によってアーキテクチャが変化してしまったのだ。
「クラウド」によって変化した考え方
次のテーマは「クラウド」。クラウドは、昨年辺りから当たり前に使われるようになり、システムの継続として重要なものとなってきた。自社サーバでは災害で落ちる可能性が高いが、クラウド化による拠点分散を実施すると、この問題を軽減できる。日本だけではなく海外のデータセンターに置く事も考えられるからだ。しかし、このようにすると、システムとコストが膨大になってしまう。
3.11により、疎・密の考え方が変わった。以前はなるべくリアルタイムに反映できた「密」を中心に考えたが、3.11ではクラウドによって「疎」を中心をした考え方に変化した。さまざまなシステムが存在するなかで、疎・密の分け方や、どこをクラウド化するか？を検討しなければならない。
従来のシステムはリアルタイムな反映が可能だが、クラウド化ではリアルタイムな反映が困難となる。データの同期を行うタイミングとしてどの位のディレイ（遅延）が許されるか？という問題がある。
また、お客様へのクラウド化による説明が難しい。グチャグチャになった説明では「それなら楽な手段・従来の手段」でという話になってしまう。クラウド化を行う場合は、それに関する価値観や利点の説明も重要だ。コストをかけて実現できることもあるが、コストをかけても困難なこともあり、割り切りは重要である。
データベースの完全同期とクラウド的疎結合
ここで、データベースの完全同期（ACID）とクラウド的疎結合（BASE）についても語られた。ACIDは手間とコストがかかる。BASEで自分たちのやりたいことができるかどうかを決めなければいけない。従来はACIDベースだったのが、BASEを前提に検討するようになってきている。
質疑応答では「ビジネスを継続させたいのであって、おまえ（顧客の要望）を継続させたいのではない」という言葉も飛び出した。
大規模Webサービスのためのデータベース技術の現在・未来
B会場では株式会社ディー・エヌ・エー 松信嘉範氏による「大規模Webサービスのためのデータベース技術の現在・未来」のセッションが行われた。松信氏は以前MySQL ABに従事し、MySQLのパフォーマンスチューニングなどを国内外に行っている。
DeNAの大規模Webサービス「mobage」事例紹介
DeNAが運営している「mobage」は、1日20数億PV。DBサーバは数百台、Webサーバはそれ以上の台数が用意され、国内数拠点のサーバセンターで管理されている。現在モバゲーには、数百を超えるアプリが存在している。
テーブルは、ユーザーIDを主キーをメインに、ログイン情報・イベントごとのユーザー情報・セッションのデータなどを紐付け生成する。しかし、ゲームによっては＋αの独自データが入ってくるため、レコード数が膨大になる。こうなると1台のサーバでは困難になるため、複数のサーバで分散させる。
ここで、同じ型のテーブルデータを複数のサーバに分ける「水平分割」がポイントになる。定番では特定範囲で1サーバへ割り当てる「マッピングテーブル方式」が使われる。分割数の剰余によってサーバを決める「剰余ループ方式」の場合は分割する数を変える時にサーバを移す手間が発生する。
スループットに応じて台数の増加をするのが理想だが、実際にはサーバ台数の頭打ちが生じる。そのため、想定以上のアクセスに応じて制限をかけるようになる。
台数が多くなると、サーバコストが生じる。コストは無視できない。結論から話すと「1台あたりの性能を高める」方法が有効だ。これにより台数を減らすことができ、コストを軽減できる。ハード・ソフトのどちらも、歴史と共に向上しているため、32ビットOSから64ビットOSに変化し、メモリも大きくなったことで、1台で処理できる性能が向上した。
しかし、高性能による副作用が発生する。マスターとスレーブで更新が変わらないため、デプリケーションによる遅延が発生してしまうのだ。そこで、スレーブにSATA SSDを使った。SSDはハードディスクの15倍と非常に速いため、SSDに変更することでこの問題を解決できた。
また、MySQLでは、この時期に複数の処理を並列で行うようになった。従来複数の処理をロックし、1つずつ処理していたものを並列処理できるように改善が行われている。また、I/O処理のスレッドやバックラウンドジョブの追加を行うことで、並列処理を行い、性能を上げるようになった。
MySQLに限らず、データベースでは突発的に発生したジョブに対して性能ダウンが生じてしまうことがある。すべての処理が一定時間何も行えなくなる「ストール」をなくす。この問題はMySQLでもバージョンアップで改善されており、新しいバージョンを使用することで改善が行える。この後「ハードウェアの進化の現在・今後」として、マスターでSATA SSDを使い、スレーブでPCI-Express SSDを使うという話に続く。
従来はマスターとスレーブで異なるDBサーバで処理させていた。これをマスター・スレーブを一緒に1台で処理させる。サーバ負荷は増えるが、SSDの速さで解決できる。これによりDBサーバの台数を減らし、コストダウンにつなげられる。
この構成で新たな問題となるのは、ネットワークのボトルネックだ。こちらの対処は新たなネットワーク構築を行うなどの方法がある。また、CPUのボトルネックも問題として発生する。この改善策としては、SQL文による対処法や、MySQLをNoSQLとして使う手法、接続方法の改善手段が紹介された。
「77回スピーカーを経験して分かったこと」共有します
休憩のあと、A会場の前半20分は、グレープシティ株式会社 八巻雄哉氏による「『77回スピーカーを経験して分かったこと』共有します」が講演された。
「スピーカーはしゃべりの才能が必要なのか」という問いについて、八巻氏は「8割の努力でカバーできる」と語る。
初心者スピーカーの壁「緊張」を乗り越えるためには
スピーカーに関するハウツー本がいくつか発売されている。ハウツー本から重要なキーワードもいくつか上げるが、これに関しては違和感を感じると言う。「プレゼンといっても幅が広すぎる」また、「すでにプレゼンができる人に向けての応用であり、入門編がほしい」と出した。ここでの入門書として仙台のプレゼンでお馴染みのオチが登場する。ジョジョだ（ジョジョの奇妙な冒険。作家の荒木飛呂彦氏が仙台出身なのと関係があるらしい）。
初心者スピーカーの壁は「緊張」。「スピーカーは緊張して当然」と、八巻氏は述べた。失敗を恐れるのが要因だが、実際にはほとんどの失敗は自分にしか分からない。努力によって緊張は軽減できる。最終的に「リハーサル（ランスルー）を行うこと」と回答を上げた。リハーサルを行うことによって2つのメリットがある。実際に行ってみることでストーリーができる点、時間配分ができる点だ。緊張がコントロールできるようになると、ハウツー本に書いてあることも実践できるようになるのだ。
そして技術セッションの場合、「決めるのは内容」。ここでいう内容はスライドではない。ストーリーになっていること、聞き手とマッチしていること。そこで出てきたのはタイムテーブルに記載されたタイトル・概要。これはスピーカーを調整できる唯一の要素である。誰に聞いてほしいのかを明記することを挙げた。
なお、この後は、特別講演として株式会社翔泳社 岩切晃子氏より「震災当時の岩手県サイトや善玉ハッカー?!の話」が行われた。
