ChefConf 2015 レポート (part 3) #getchef
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
2015年3月31日から4月2日まで実施されたChefConf 2015の現地レポートpart2です。
Panel Discussion:
Cade Mets: Editor. Wired
Jeff Arcuri: Senior Director of IT, GAP
Phil Divobitz, Production Engineer, Facebook
Mark Russinovich: CTO Microsoft Azure
Facebook:
Facebook内でオープンソースベースの開発に従事
ハードウェア、サーバプラットホームも含めて社内の技術を積極的にオープンソース化している
自社のコア技術は独自仕様でいいが、例えばインフラレイヤーはFacebookのコア技術じゃないので、そこはオープンソースを使うのは当然
Microsoftがオープンソースに投資しているのは非常に大事な事。MSがオープンソース志向を持っているのであれば、逆にできない会社はないはず。
OCPのオープンソース化は、ハードウェアのコストを下げるのに大きく寄与している。（大量のサーバを買うFBとしては嬉しい）
インフラ側にいる人間も、アプリケーション開発者のコンセプトを導入している。
セキュリティは個別のコンポーネントではなく、他のコンセプトの一部としてDevOpsに統合されていく。
全てのコードはgitHubにアップしている。
Gap
オープンソースを積極的に採用している。そこに最も新しい技術が存在する、というのが最大の理由。特にビッグデータとアナリティクスの領域は顕著。
Chefを使って運用を行なっている
オープンソースがソフトウェア技術を最も牽引している領域である。そこに参画しない理由が見つからない
セキュリティは非常に重要で、新しい技術導入時に必ず検討している。
いろいろな人からのアイディアを取り入れてよりよいものを作ることができるのがオープンソースの魅力
Microsoft Azure
オープンソース志向への転向を見てきた（.Netのオープンソース化）
全て自社開発する、という考え方はもはや古い。
従来のエンタプライズ企業がオープンソースを採用するに伴い、Microsoftも移行が必要、と判断
Windows事業は今後の継続しイノベーションを提供する。しかし顧客のオープンソースへの移行と共にMicrosoftも対応しているだけ
OpenStackに参画し、開発もオープンソース化している。
オープンソースでのセキュリティ：大量のツールが存在するが、高度な技術やツールはまだ個々の企業のコア技術出会ったりするのでまだオープンソース化されていない領域である、と言える。
会社規模が小さくても、MSと同じクラスの規模でインターネットアプリを運用する会社はこれから増加する。MSでのオープンソースの運用方法は決して大きい会社に限定されているものではない、と思う。
観客の中で、Windows onlyの会社があるかどうか聞いた所、ほんの数社しかいない。これが現実であって、Microsoftはそれに応えていくだけ。
Windowsのオープンソース化も決して不可能ではない。10年以上前には文京市場向けのWindowsのオープンソフトが存在した。
オープンソースは自社のCdePlexではなく、gitHubにあげている。
John Byrne, Cloud Services Engineers, Scholastics, Inc.
ニューヨークに本社を置く、教育コンテンツを取り扱う企業
世界最大の児童書の発行
Scholastics Book Clubは教育業界で非常に大きいe-commerceサイト
先生向けのオンラインコンテンツを提供
学生向けのゲームも運用
Chefを使った、企業内のDevOpsの自動化に力を入れている。
インフラの状況
ベアメタルから、95%を仮想化している。
AWSとvSphereのハイブリッド環境
ほとんどのアプリケーションはChefで自動プロビジョニングや環境管理を運用している
以前と比較して、プロビジョニングが非常に早くできるようになった。
サーバの構築後はまだマニュアルの作業が多い
スケーリング
負荷分散プール等のネットワーク関係
トラブルシュートもマニュアルで行っている
その後の処理（Chefクライアントサービスの再起動、Cookbookのアップデート等）もマニュアル
問題解決の手法として、「ペット」と「家畜」の理論を採用した。
「ペット」は、カスタムホスティングを提供される。トラブルシュートを通してパッチを提供するなど、きめ細かい世話をする。
「家畜」はもっとブラックボックス化されたインフラ環境で、トラブルシュートは直すのではなく、新しいのと入れ替えるだけ。
「家畜」はEC2運用で採用：
knifeコマンドでEC2インスタンスは作らない
AWS機能で自動スケーリングを採用（新規サーバの設定情報をあらかじめ決めている）
グループ内で生成されたサーバは自動的にChefでプロビジョニングされる
「家畜」は自動化
自動スケーリンググループがクラスターを監視
負荷分散機能に従って、ノードの増減を自動調整
サーバに対するチェックを定期的に行い、障害を起こしているノードを外す
プロビジョニング機能はChefが実施（自社開発のCookbookを使用）
レガシーアプリはまだ「ペット」状態
Statefulなアプリ（例えばDBサーバ等）は「ペット」として運用する必要が残る
新規アプリはStatelessを心がける
レガシーアプリは、state情報をS3バケットに保存したり、DBサーバに保存したり、影響を受けるサーバを少なくする
さらに運用の自動化
自動スケーリング向けのマシンイメージを事前に作成、PackerとChefを使って自動プロビジョニングを容易に
コンテナ
Packerの設定を簡単に変えて、イメージからコンテナを取り扱うようにした
開発工程で主に使っている
プロダクションでは、コンテナのスケジューラを幾つか評価をしている最中でまだ決めていない（Kubernetes, Mesos, AWS Container Service、等）
デモ
PackerでDockerコンテナをビルドするスクリプト
簡単なJSON表記で読みやすい
