基盤開発観点からみたはてなのAWS活用のこれまでとこれから

こんにちは、id:wtatsuru です。この記事は、はてなエンジニア Advent Calendar 2018 8日目の記事です。昨日は id:taketo957 による aws-cdkを用いた開発事例の紹介 - taketo957の日記でした。
このエントリでは、はてなでAWSをどのように使ってきたかを、サービス基盤の開発・運用の観点から振り返ります。

黎明期

はてなで最初にAWSをプロダクションに投入したのは2011年、はてなブログβリリース時でした。当時は EC2 のみのオンプレミス側と同じ構成からスタートしています。

VPNを張って共通のネットワークに置き、監視やセットアップでもオンプレミス側となるべく共通のものを使う、という思想で構築・運用を開始しています。今で言う EC2 Classic のみ、アカウントもrootのみという古典的な時代ですが、ELB, VPC, RDS など徐々にリリースされていくクラウドサービスを検証・導入していきました。オンプレミス側ではSSDがバリバリ活躍し始めた頃ということもあり、I/O 性能が出ずに苦しむことも多かった頃です。

共通基盤構築と利用の拡大

その後、AWS利用のノウハウが溜まって基盤整備が進み、新規構築でクラウドを使うことも多くなってきました。はてなとしては、Mackerel のリリースなどサービスの幅が広がっていく時期でもありました。

多くのサービスへ利用を拡大していく中で、はてな全体で共通の基盤を使っているゆえの課題が出てきました。
例えば、IAMの権限をAWSサービス単位で広く取っている物が多いために、別のサービスリソースを触ってしまう危険性があり、コンソールを触る際の安全性が低い、などが挙げられます。1つのものを触るときに影響する範囲が大きく、基盤レイヤに何かを導入するときには既存の共通基盤や多様なサービス全体を見る必要があるため、基盤開発メンバ以外がさわりにくい状況が生まれており、改善の速度自体にも課題を感じていました。
費用管理上も、どのサービスがどれくらい使っているのかわかりにくい、という課題がありました。この点はタグベースの費用分類である程度解消しています。サーバ構築時に流れる chef recipe から動的にタグ付けするなどの運用により、サービス単位の利用料金を把握できる状態としています。
コスト配分タグの使用 - AWS 請求情報とコスト管理

アカウント分離

クラウド利用が進み、そのメリットを活かしたサービス開発が行われる時代が来ました。はてなでも、Mackerel の AWSマネージドサービスを使った時系列DBの構築や、はてなブログの独自ドメイン証明書基盤などが開発され、今後ますます広がっていくと予想されます。プロダクト単位で必要なサービスをいかにうまく使えるかがサービス開発の鍵になります。

そんな中、基盤部分をある程度独立させてサービスレベルのスケーラビリティを高めて開発速度を上げることを目的として、AWSアカウント単位での分離を進めています。AWS Organizations や VPC Peering などアカウントを増やしやすい状況も後押ししています。
基盤開発観点では、開発者が触りやすいように社内構成のドキュメントの整備とガイドラインの策定を行いつつ、アカウントを増やしやすい仕組みや、社内の標準形を探る検証を行っています。今年のインターン成果もその一例です。

以前から続いているサービスも多いためまだ分離は一部のサービスのみですが、新規構築分では分離しながら、既存アカウントのマイグレーションも徐々に進めていく予定です。今年の re:Invent でもマルチアカウントを助けるサービスが次々発表されています。AWS Transit Gatewayでネットワーク構成は大きく変わりそうですし、AWS Resource Access Manager もかなりマイグレーションに役に立ちそうな予感がしています。目まぐるしくベストプラクティスが変わる状況ですが、うまくサービス開発をスケールさせることができる形を探っていきたいと考えています。

おわりに

はてなでAWSをどのように使ってきたかを、サービス基盤の開発・運用の観点から振り返りました。サービスの成長やAWSの変化によってそのときどきでのベストプラクティスは変化していきますが、うまく活用していきたいと考えています。
サービス開発を加速する基盤を作りたいエンジニアも大募集中です。
SRE (Site Reliability Engineer) 職 - 株式会社はてな

明日は id:papix です。