🦔

各社の事業を支えるインフラストラクチャ―【EngineeringTeamPresentation】

3 min read

概要

2021/08/11に開催された下記勉強会のメモです

https://sansan.connpass.com/event/214765/

セッション

ZOZOTOWNにおけるインフラの最適化

  • 2017~
    • オンプレ->参照ワークロードをクラウド移行
    • 根本のアーキテクチャは改善せず
  • 2020~
    • マイクロサービス化
    • 課題:負荷対策、運用業務(セキュリティ)、監視
      • CDN
      • CSIRTの立ち上げ, NCA加盟
      • 自動化推進
      • Splunk
    • CAPEX->OPEXへ
  • リプレイスを開始する上で整えておくこと
    • なぜリプレイスするのかを明確に
    • クラウドとオンプレでチームを分断しない
    • ロードマップの定期的なすり合わせ
    • 既存環境開発メンバーへのケア
      • 否定的な論調が強くなりすぎていないか

https://techblog.zozo.com/entry/20201105-meetup-report
https://techblog.zozo.com/entry/zozotown-onpremises-automation
https://techblog.zozo.com/entry/splunk-easy-to-use-dashboard
  • 移行に当たって体制の変更や教育はどうしたか?
    • 移動が活発なため、知識の共有につながった
    • 柔軟な組織体制
  • セキュリティ課題をどうしたか?
    • オンプレ<->AWSはダイレクトコネクト
    • コストあまり変わらない

大規模ゲームタイトルのIaaSコストマネジメントへの技術アプローチについて

  • オンプレとクラウドではQCDのうちコスト削減が課題となっていた
    • Qは同等、Dはクラウド優位
    • Cはオンプレ優位で50%にしないと同じレベルにならなかった
  • 既にクラウドで動いているもので検証
    • AWSのベストプラクティスに沿って
    • スポットインスタンス
      • オンデマンドでは2分前の告知で落ちるが実際には間に合わない
        • サーバ起動してサービス可能になるまで3〜5分
      • 解決のポイント
        • スポットプールを多数使用して落ちるタイミングを分散
        • プールのインスタンスの性能を揃える
        • スポットがたたないプールはオンデマンドを立てる
    • AutoScale
      • 独自のスケーリング
        • CPU使用率を取得してDBへ、autoscale
      • セカンダリIPをインスタンスタイプごとに割当数を変えてロードバランス
    • Sharding
      • ローンチ直後はユーザが多いが一部のユーザーはアクティブでなくなる
      • メンテナンスを入れずにshard統合する
      • インスタンスのIOPSを生かす
      • 統合集約のためのスクリプトを準備
        • MHA
        • Auroraより圧倒的性能
      • 1台のインスタンスに複数のMySQL, セカンダリIPに対応

AWS Summit Online 2021 基調講演

https://fullswing.dena.com/archives/7425
動画
https://www.youtube.com/watch?t=25m16s&v=AIoItC51iac&feature=youtu.be

IOPSについて

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/storage-optimized-instances.html

https://engineer.dena.com/posts/2020.01/spot-instances-availability/
https://engineer.dena.com/posts/2019.12/multi-instance/

事業の根幹を担うデータ化システムのインフラのこれまでとこれから

  • CloudSearch->Amazon Elasticsearchへ移行
    • 可用性向上
    • コスト削減
  • ログイン承認制
    • (ここは非公開)
  • 名刺データ化システムのコンテナ化
    • ECS on EC2
      • datadogで監視
    • ecscheduleでスケジュールタスク管理
    • デプロイ管理
      • CodePipeline + CodeBuild + ecs-cli
      • api gateway lambda でslackから手動承認
        • 今ならecspressoがおすすめとのこと
    • Rails Consoleは独立したECSサービスに

https://buildersbox.corp-sansan.com/entry/2020/12/02/110000
https://github.com/kayac/ecspresso

組織と事業の急拡大に立ち向かうためのマルチテナント Amazon EKS クラスタ/マルチアカウントアーキテクチャ

  • サービスとインフラチーム
    • インフラチームが各サービスチームをサポート
  • サービスチームへの移譲
    • アプリケーションの実行環境管理:docker
    • サーバーリソースの管理:k8s
    • ミドルウェアの管理:AWS
  • Docker + k8s + AWSによるインフラの移譲
    • マルチテナント EKS
      • 単一クラスタに複数サービス
      • 技術的ギャップが大きいのでクラスタ管理はインフラチームで
        • チームが成長したらシングルテナントへ分割
    • マルチアカウント
      • サービスごとでアカウント作成
      • 統制やネットワーク課題はインフラチームで
  • アーキテクチャ
    • Transit Gatewayによる接続
    • Direct Connectでオンプレに接続
  • 開発フローの変化
    • 以前はインフラチームに作業を依頼してもらう形だった
    • 新しい構成で開発フローはサービスチームでとじる形になった
      • AWSはTerraform, k8sはArgoCDを利用
      • 必要ならインフラチームにレビューリクエスト

全体質疑

  • AWSのインフラを管理するにあったてどのくらいのスキルレベルが必要か?
    • レベル感で言えばソリューションアーキテクト アソシエイトくらい
    • AWSを習得、習熟しようとする力、キャッチアップが大事

Discussion

ログインするとコメントできます