ishida

2014.12.03

Inside of Allied Architects(Advent Calendar3日目)

挨拶

アドベントカレンダー3日目を担当するポケモントレーナーの石田です。ORAS発売されましたね!皆さんは、もうチュートリアルも終わって厳選態勢に入っているのではないかと思いますが、僕は諸々あって厳選態勢には一歩出遅れている状態です。いっそ、なりふり構わずORASで捕まえたポケモンを環境の整っているXYに連れていってXYで厳選しちゃおうか悩むレベルです。ORASチュートリアル部分の一番の思い出は、御三家と伝説については一期一会主義であるにも関わらず「のんき」な「ラティオス」と出会った瞬間、一期一会主義を曲げそうになったことです。ちなみにジュカインも「のんき」です。

「ポケモンのOOPどうすんだ?」って感じですが、「アドベントカレンダーなのに会社由来の話じゃなさ過ぎる」ということで、前々から何度か書こうとして「ボツ」にしているネタを取り扱ってみようと思います。

DB

現状はMySQL一択になっています。

開発言語

ズバリ現在中心となっている言語は以下の3つです。

  • PHP(Web)
  • Java(Core, クローラー, Android)
  • Objective-C(iPhoneアプリ)

この他に、サービスによっては以下の言語も使用しています。

  • Scala(Web)
  • Python(Web)
  • Swift(iPhoneアプリ)

基本的にはPHPを中心に据えています。ただし、「PHPで書くことが不適切な部分については、その限りではない(例えば、大量計算を伴うものや型に厳しくあって欲しい箇所)」という扱いにしています。個人的にはRDBをラップしてHTML生成のための文字列操作をする層の言語の良し悪しについて熱く議論することは「コーヒーが好きか紅茶が好きか」について熱く議論しているのとあまり変わらないと思っている(完全な不足があるならともかく、必要十分な機能を有する言語同士でという意味)ので、そこに時間を使う位ならば中心となる言語を統一することで、緊急時に誰もが、どのサービスについてもhotfixし易い状況を作る方が好ましい考えています。では、何故PHPなのか?というと「黎明期から、この会社のプロダクトにはPHPが多かった」ことと、RDBをラップしてHTMLを生成するのに必要十分な機能を備えていると考えているからです。もし、より適切な選択肢があり、イニシャルコストが見合うようであれば、別の言語に取り替えても良いかなと考えています。例えば、Hack言語とか。

Coreについて

「Javaの項に出てきたCoreって何だよ?」って話ですね。結論から言うと「共通で使う特定ドメインのモデル層(データ + データ操作)を詰め込んだThriftのServer」です。Javaで記述されています。いわゆる、分割統治ですね。なお、Coreのインターフェースは抽象化されており「ThriftのServer」だけではなく入出力を定義することでCLIからもWebからも同じロジックを利用出来るように作られています。

フレームワーク

PHP

  • Curely(読み:キアリー)
  • Curely2(読み:キアリー2)
  • Laravel4
  • Zend Framework

Java

  • Hibernate
  • Seasar2
  • Thrift

Scala

  • Play

キアリーについて

キアリー、キアリー2は自社製のフレームワークです。キアリーはPHP5.1とかの時代をターゲットにして作られておりキアリー2はPHP5.4以降をターゲットにしてマイグレーションされています。「フレームワーク層に起因する問題があった時、社内エンジニアが誰でもhotfixできること」「アーキテクチャを統一することで担当サービスを跨ったエンジニアがhotfixし易いこと」を目標に自社フレームワークを採用しました。キアリーが作られた経緯としては、世に転がっているPHPのライブラリ類が海千山千過ぎてヤバかった(という印象を受けていた)からですが、現代は品質も揃ってきているので自社フレームワークに拘るよりは、技術者の多いオープンソースフレームワークの採用を検討するべきかな?とも思い始めています。なお、キアリー2には以下の特徴があります。

  • DIおよび注入指向のアーキテクチャ
  • HibernateライクなORマッパー
  • 緩いMVC
  • 緩いルーティング
  • 緩いレスポンス定義
  • DBマイグレーション
  • オプティマイザ

オプティマイザっていうと凄そうに聞こえてしまうので、誤解が無いように補足します。ここで言うオプティマイズは「アルゴリズムを自動最適化」とか、そういったアクロバティックなものではなくて「実行時のディスクアクセスを減らす」という凄く地味な機能です。具体的には基本的なルーティング、細かく分割されている設定ファイル、DocComment内のアノテーションを解析した結果をキャッシュして1ファイル化、フレームワークの中核クラスを1ファイル化するというものです。基本的にはmsec単位の影響しかありませんが、WebAPIとして利用する場合や、スパイクアクセス時には、こういった地味なチューニングが効いてくるので搭載しています。

インフラ系

  • AWS
  • Xen・KVM
  • Chef
  • Ansible
  • Vagrant(開発環境構築)

AWSとデータセンターを併用している状況です。振り返ってみるとアライドの歴史の中でも、ハードウェアの仮想化は割と早い段階から取り組んできたのではないかなと思います。とは言え、現状でも構築するサーバーの量が非常に多く、また、来年も増えていく見込みがあるので、インフラエンジニアに負担をかけ過ぎないように、もっと工夫していきたいところ。※インフラエンジニア積極採用中!です

運用系

  • Capistrano(デプロイ)
  • 自家製デプロイスクリプト(デプロイ)
  • munin(サーバー監視)
  • nagios(サーバー監視)
  • Hubot(障害検知)
  • Jenkins(CI・外部APIのヘルスチェック)

ソースコード管理

  • Git(メインのバージョン管理)
  • GitLab(GitのGUIとして利用)
  • Subversion(移行残り)

情報共有

  • Google Apps(メール・チャット・カレンダー)
  • HipChat(コミュニケーション・障害検知)
  • Redmine(障害票・障害報)
  • Backlog(タスク管理)
  • Confuluence(情報共有)

最後に

いい加減9年目の会社(来年は10周年!)ということで、棚卸ししてみると同じ目的の技術やツールが散見されますね。「歴史的経緯」や「移行しきれていない」や「流行に乗ってみた」等の理由でとっちらかっている部分もあります。でも、変化の早いWeb業界において9年間も作り続けてきたことを考えると、とっちらかり具合は軽度なのかな?という印象も受けます。というのも何かを採用する時、単に「面白そうだから」とか「あの会社がやっているから」とかの理由で採用するのではなく「本質を見極めて採用してくることが出来た、もしくは不要なものを淘汰してきた」からだと考えています。アライドアーキテクツでは来年の10周年に向けて、10年後も通用する「本質を見抜く力」を持ったエンジニアを募集しています。まさかの、1記事に二度の採用オチ