はじめに
初めまして。サイバーエージェント メディアディベロップメント事業部（MDH）でナンデモエンジニア（アーキテクト、クラウドインフラ、プログラマ）をしております、平松紘典と申します。
現在私の所属しているMDHは、弊社の展開するさまざまなメディアをさまざまな方法でマネタイズする事業部です。中でも広告分野に関してはカオスマップの大部分を網羅する数多くのシステムを内製しており、技術者組織も30人を超える規模になっています。
私たちは「新技術」や「枯れているけれどチーム内に経験者が居ない技術」を取り入れることを「技術的挑戦」と位置付け、それが著しく事業への好影響を与えることを説明できる場合には、工数増などのある程度の一時的なリスクは許容して積極的に受け入れる文化を作っています。
先日開催された「オレシカナイト」は、技術的挑戦を行う過程で技術者達がハマった・失敗したポイントを発表し、みなさんが挑戦する際の参考にしていただきたいというコンセプトのイベントです。
MDH内で隔週で行っている勉強会「LT Thursday」のスピンオフとして開催されましたが、社外の方に公開した結果、多数のご応募・参加をいただけたイベントになりました。
今回は、その内容を詳しくレポートします。
1. PackerとAnsible でコンパクトに始めるInfrastructure as Code（平松 紘典）
最初は平松の発表で、AMIを手運用することで生まれる問題とそれをPacker＋Ansibleでどう解決したか、という内容です。
AMI運用あるある
広告配信の開発がスタートした当初、私達にとってはAWSで環境を構築することそのものが技術的挑戦でした。オンプレ物理サーバでの構成管理といえばAnsibleやChefが社内でも浸透していましたが、オートスケーリングで生まれては死んでいくEC2の管理については、私達のチームでは起ち上げ当初のドタバタも相まってAMIにインストールしてあるものがドキュメントに一部記載されている程度でした。AMIを取っておけばいつでも構築できることに慢心し、AMI自体の管理がお座なりになっていたのです。これによって生まれる問題を、「AMIの森化問題」「秘伝のタレ化問題」という2つの側面から紹介しました。
AMIの森化問題
これはマシンイメージ運用に特有の問題です。
AMIからインスタンスを起動・セットアップを行い、新たなAMIを作るという作業はとても簡単なので、各コンポーネントを担当するアプリエンジニアによって無秩序に増殖されていきます。
結果、以下の図のような（もっと酷いかもしれない）状態になりがちです。
ここで、例えば根本の辺りでセットアップしているミドルウェアにセキュリティアップデートがあった際に、どのAMIにそれを適用して周ればよいのかを特定していくのは至難の業です。また、管理上いずれは消して良いノードの特定も必要になってきますが、この状態ではそれも難しくなります。
秘伝のタレ化問題
これは物理サーバの手運用で起こっていたものと全く同じ問題です。
上の図のapp Dが動作している元のAMIを切り取って見てみましょう。
td-agentのインストールなど、もはや記憶の彼方です。
ドキュメントに残していくという手もありますが恣意的になりがちですし、設定ファイルの変更も含めると構成管理ツールに任せたほうがお気楽です。
Ansible＋Packerの導入
上で紹介した問題たちは、AMIの構成管理にAnsible・Chef等の既存のソリューションを導入すれば解決します。
ではPackerが何をしてくれるのかというと、
- 元のAMIから一時的なインスタンスを起ち上げ
- 任意のシェルスクリプトや構成管理ツールでセットアップを行い
- スナップショットを撮ってAMI化し
- 一時的なインスタンスを削除する
というAMI作成の一連の流れの自動化です。
ここで、「元のAMIはAmazonの提供するPublic AMIであること」というルールも定めました。常に生のLinuxへの適用になるため、構成管理の冪等性に関してはあまり神経質になる必要はありません。
これにより、各AMIの関係は以下の図のようになります。
構成管理がコードに落ちることにより秘伝のタレ化が解決し、元のAMIを生のAmazon Linuxに限定することによってAMIの森化が解決しました。
1.のまとめ
「今更かよ」と思われることも覚悟しつつの発表でしたが、イベント終了後の懇親会では「ウチも手運用だ」という方がチラホラいらっしゃいましたので、マシンイメージへの構成管理ツールの導入はまだまだ浸透していないのかもしれません。この記事をご覧になっている方でまだ導入されていない方は、是非早めに手を打ってくださいね。
