SREチームのミッションを体現するシステム設計思想

この記事は、eureka Engineer Advent Calendar 2017 23日目の記事です。
22日目は後藤さんの「Hello Blockchain」でした。

こんにちは！CTO SREチームの恩田です。
2015年にエウレカへ入社後、インフラチーム配属を経て現在はSREチーム責任者及びチームPOを兼ねて働いています。

今回の記事は、弊社SREチームのミッションの紹介から始まり、翻って昨年時点で抱えていた我々の課題と、それらに対しどのように課題解決をおこなってきたのかを順にご紹介していきたいと思います。

我々は何のために存在しているのか

元々infraチームという名前で存在していたチームと技術基盤チームが合併して現在のSRE(Site Reliability Engineering) という組織になったのですが、そのタイミングで我々のチームミッションを再定義しました。具体的には、以下6つをチームのミッションとして掲げています。

• 99.95%の可用性を目標に、事業的な機会損失の最小化をめざす
• ブランドイメージ失墜につながるクリティカルなセキュリティリスクを撲滅する
• 運用の自動化及び自己修復可能なシステムを構築し、少数での運用体制を確立する
• 適切なキャパシティプランニングを行い、利益率向上へ寄与する
• 顧客価値提供を最速化する為のリリースエコシステムの改善と安定化をおこなう
• 事業価値最大化にむけた施策の技術サポートを行う

また、責任範囲としては弊社エウレカが運営しているオンラインデーティングサービス”ペアーズ”のアプリケーション実行環境を始めとした社内ITを除く全システムを担当しています。

サービス及びシステム特性

次に、我々が運営する主力サービスであるオンラインデーティングサービス”pairs”のサービス及びシステムの特性について紹介します。

セキュリティ要件

オンラインデーティングサービスという非常にプライバシー性の高いサービスかつ、個人情報を扱うサービスという事もあり、情報流出がもし発生すれば会社の事業継続において致命的です。どんなWebサービスであろうと情報流出は当然許容できませんが、特に気を配るジャンルのサービスであると言えます。

アクセス特性

平日で言えば、社会人の可処分時間帯(夜間)での利用が多く、時間帯毎のアクセスボリュームの差が大きいのが特徴です。

事業スケール

エウレカは現在pairsのマルチリージョン展開を事業拡大の中心戦略に据えています。事業は非常に好調であり、組織規模拡大以上のスピードでサービス規模が拡大している状況です。

開発スピード

社員の半数以上が開発者であり、かつ正社員開発者は基本全員がリリース可能な権限を与えており、営業日は日に10回を超えるリリースが行われる事も珍しくありません。

事業継続・拡大におけるシステム課題

このようなシステム/組織特性に対し、昨年度時点では以下のような課題を抱えており、全体的にやや機能不全に陥っていました。

アクセスに応じた柔軟なワークロード調整が出来ない

我々はアプリケーション実行環境としてAWSを全面的に利用していますが、ステートレスレイヤのAPIサーバを例に上げると、サーバがサービスインするまでに以下4つのステップを踏む必要があります。

• 1:実行筐体(EC2)の立ち上げ
• 2:ミドルウェアのセットアップ
• 3:アプリケーションのデプロイ
• 4:ロードバランサへのアタッチ

1はterraform、2,3はansibleでそれぞれコード化され自動化はされていたのですが、サービスインまでのステップが多く最終的なELBのアタッチは人力で行う必要があるなど、サーバをサービスインまで持っていくのに30分以上かかる上、人力でのステップ実行が必要な状況でした。結果としてピークタイムに合わせたワークロードを常に確保している状態になっており、コスト観点で効率が悪い状態でした。

またピークタイムでサーバが悲鳴を上げ始めたタイミングで即対応な可能な状況とは言い難く、増強完了前にパフォーマンスが劣化し始める状況もたびたび発生していました。

内外セキュリティリスクの可視性が低い

いわゆるクローリング系ツール(足跡つけまくるようなやつ)、管理画面ログイン試行や各種インジェクション試行など、外部からの悪意あるアクセスに対して対策をしていない & 攻撃されても気づけない状況でした。

また、ネットワーク内部の各サーバの関しても、脆弱性評価やベストプラクティスからの逸脱がないかを可視化出来ておらず、潜在的なリスクを抱えたままとなっていました。

セキュリティパッチ適用がしづらいプロビジョニング方法

バッチタスク実行サーバや、アプリケーションビルド/deployを行うサーバ、開発者の物置と化していたbastionサーバ、データバルクロード用途のサーバなど、コード化されておらず再現性が無い & サーバ切り替えがしづらいサーバが随所に散乱している状態でした。

またコード化されているサーバも冪等性保証がされているとは言えず、結果としてレシピに信頼性が無いため特にステートフルサーバを中心としansibleレシピが機能していない箇所が多々あり、結果としてパッチアップデートのしづらさを抱えていました。

ネットワーク構成のポリシーの無く守る面が多い

pairsの本番ネットワークに関しては大分前の記事ですがこれだけ押さえておけば大丈夫！Webサービス向けVPCネットワークの設計指針で書いた通りの3tier Architecture x TerraformによるVPC管理といった標準構成を取っていましたが、リージョン毎の差異が存在していたり、ステージング環境やマイクロサービス、コーポレート系サーバやオウンドメディア等は引き続きグダグダといった状況でした。

また、ロードバランサを介さずSSLオフロードされないままインターネットアクセスを受けてるサーバや、SSHがbastionを介さず直受けかつデフォルトポートになってるサーバ、IP Restrictionの実現方法がリバースプロキシレイヤだったりNetworkACLだったりSecurity Groupでやっていたりとまさに混沌とした状態のため、管理コストが高い状態でした。外部侵入対策でまず考えるのは外部との露出点ですが、守るべき箇所が増えると当然リスクは増えるため望ましくありません。

目指すべきシステム像

これら課題を因数分解し、以下の状態への移行を理想形としてシステム/チームの変更へ取り組みました。

• アクセスに応じてワークロードを柔軟かつ簡単に調整できるダイナミックなインフラストラクチャ
• サーバの交換性を高め、パッチ更新等システム疲労を解消しやすいプロビジョニング体制の確立
• エウレカで管理する全システムの技術標準化およびコード化を進め、コントローラブルかつ再現性の高い状態
• 外部攻撃への自動防御機構、および内部脆弱性の透明化と目に余るパッチ作業工数へ時間投資し易いチーム体制
• システム複雑性の増加を押さえ、システム規模に比例しない運用工数で可用性/冗長性を維持できる体制

技術戦術

上記を実現するため、今年1年で以下の改革を完了させました。

Packer x Ansible x TerraformによるGolden AMIモデルのプロビジョニング

同じくSREチームのさかじゅんの記事、Pairs Infra 2017に詳しく書いています。

一度サービスインしたサーバへ変更を加えない、サーバへ変更を加える際はサーバごと再作成する方式に寄せきる事で、コード化におけるレシピの冪等性担保の心配がなくなり、また構成ドリフトが起きない体制になりました。

ASGによるパッチ済みサーバのblue green rollout手法の確立

上記プロビジョニングモデルで作成したサーバは全てASGを利用してサービスインさせます。ASGは起動設定のAMIを変更しても稼働中のサーバはそのままの状態なので、この仕組みを利用しています。具体的には、以下の流れでサービスインを行います。

• Terraformでパッチ済みAMIに起動設定を変更
• ASGのdesired capacityを1台増やしパッチ済みEC2を1台サービスイン
• ヘルスチェックが通っており、かつシステムアラートが上がってきてないことを確認
• desired capacityを倍へ。パッチ済AMIから作成したEC2を全台サービスイン
• desired capacityを元に戻し、旧稼働中サーバを全て退役させる

この流れで行う事で、パッチ済サーバの段階リリースが可能になり、切り替え時の障壁が大きく下がりました。

ステートフルサーバのマネージド化 + RI導入

逆に、上記モデルが取りづらいDBやCacheレイヤは全てAurora / Elasticacheに寄せ切る事で、セキュリティパッチ等の管理コスト自体を下げる方針にしました。 また、キャパシティ調整はマネージドでも柔軟に調整が難しいケースも多いので、余裕をもたせたプランニングにもとづき構築し、RIのAll Up Frontで単価を下げる事で単位時間あたりのコストを上げずに運用コストをさげ、セキュリティを向上させています。

ASG x CodeBuild x CodeDeployによるワークロード調整と定常ローテート

APIサーバ、各種マイクロサービス、Dequeue workerといった部分は全てASG x CodeBuild/Deployでサービスイン + キャパシティ調整
が可能な形にしました。また、社内管理画面やbastionといったワークロード自体の増減が無いサーバに関してもASGのschedule eventで定期退役 + 再作成を毎日繰り返すようにしています。1サーバの寿命をなるべく短くすることで、手動変更による構成ドリフトの防止やバックドア対策を行っています。

3 tier architectureへの全面以降とIP Restriction方法の統一

日本、台湾、韓国それぞれのPairs本体や付随する各マイクロサービス、これらの本番やステージング、さらにコーポレート系サーバやオウンドメディア運用サーバなど全てのNetworkを刷新しました。外部露出点をbastionサーバとELBの443ポートに絞る事で潜在リスクを減らし、かつ全てのVPC構成をTerraformで構築することで管理コストも下げています。

また、IP制限等の実施は全てSecurity Group管理に寄せ切り、同様にTerraformで管理可能にコントローラブルな体制かつセキュリティホールが存在しづらい体制へ移行しました。

(設計詳細は、これだけ押さえておけば大丈夫！Webサービス向けVPCネットワークの設計指針の方で書いているので割愛)

StackDriver Logging x CloudPubSubによるログ集約

アプリケーションログ、および各種AuditログをStackDriverで可視化し、開発者がサーバへ入らなくてもログを見れる体制にしました。
また、最終的なログ集約先を全てBigQueryとし、エラーレートやトレンドの把握等を別途redashで可視化しやすい状態にしました。

Akamai WAFによる外的攻撃からの自動防御

Akamai社が提供するファイアウォールを導入しました。動的コンテンツ配信用endpointの名前解決先をAkamaiのファイアウォールが設置されてるEdgeロケーションに向くようにし、すべてのトラフィックを検閲、悪意のあるアクセスがあった場合は自動防御が展開される仕組みにしました。

AWS Inspectorの定期自動実行による脆弱性検知の自動化

全EC2にAWS Inspector Agentをインストールし、それをlamba x cloudwatch eventでkickする事で全サーバのセキュリティ診断を毎日実施、脆弱性を可視化しました。このレポートはチームのDailyミーティングやweeklyで行っているパフォーマンストレンド定期チェックミーティング等で全員で確認するようにしており、脅威度の高いリスクがあった場合は優先度を上げてチームで対応するようにしています。

終わりに

システムや組織に完成形はありません。何よりも大事なのは継続的な改善努力を続けていくことだと私は思っています。
来年も、今よりさらにユーザへ安心、安全、快適を届けられる体制を目指し努力していきます。