AWSの運用自動化サービス Cloud Automator で”攻め”のシステム運用 AMIMOTO スタック編 レポート

リンクバルの川畑です。先日サーバワークス様・デジタルキューブ様主催の「AWSの運用自動化サービス Cloud Automator で”攻め”のシステム運用 AMIMOTO スタック編」に参加しましたのでその内容をまとめました。

目次

AWSの運用自動化サービス Cloud Automator で”攻め”のシステム運用 AMIMOTO スタック編

デジタルキューブ 小賀 浩通 / 堀家 隆弘 / 岡本秀高(40分+質疑応答)

はじめに

  • 本日のメインはあくまで「Cloud Automator」
  • Amimotoとは
    • WordPressがインストールされたAMI
    • AWS Marketplaceで提供
    • サーバ構成はEC2インスタンス1台からRDS(Aurora)まで対応
  • 事例紹介
    • Japantimes etc…
    • アメリカ・シンガポールでも
  • WordPressユーザーの目的は
    • コンテンツの公開!それ以上でもそれ以下でもない!
  • AMIMOTOを利用すればAWS上に数クリックで
    • ユーザーはビジネスに集中できる!
    • Amimotoの裏側はChef
    • ChefのコードはGitHubにも上がってるのでご自由に
WordPressの課題
  • AWSのスケーラビリティを最大限に発揮できない
    • WordPressの深い闇
  • 肥大化し続けるデータベースと大量のPluginによる密結合化で、メンテナンス不能状態
    • WordPressはオートスケールするシステムには向いていない
    • プラグインを入れれば入れるほどDB肥大化

プラグイン追加によりDB肥大化してしかも密結合パフォーマンスが遅くなって
とりあえず使っていないものを無効にしても、WordPress本体とプラグインが密結合で削除できない
この辺りはWordPressで運用しているシステム共通の問題でまさに深い闇!

WordPress課題の解決方法
1.JIN-KEI CloudFormationによるInfrastructure as Code with WordPress
  • 今までの構成は結局
    • EC2なので
      • AWSのサービス使えていない
      • 自動化できていない
  • マネージド・サービスの活用
    • AWSでは
      • RDS
      • S3
      • CloudFront
      • Certification Manager
      • etc…
  • CloudFormationで冪等性
    • マネージド・サービスをつかっても構築が複雑化してしまったら結局人力に依存
    • コードでリソースを定義
    • kumogataでユニット化(←便利そうなrubyのツール)
    • WPプラグイン連携も自動化
    • Amimotoで使用しているCloudFormationテンプレートはGitHubに公開している
    • そしてAWS MarketPlaiceにも公開している
2.MicroService
  • WordPressの問題点
    • ソースコードの肥大化
    • DBの肥大化
    • DBが単一障害点となる
    • Auto Scalingが無意味に
    • 機能とコア、テーマが密結合に
  • MicroSevicesによる疎結合の機能実装
    • システムを複数のコンポーネントで構築
    • コンポーネントはそれぞれ独立したシステム
    • RestfulAPIで疎結合
    • インフラメンテナンスからの解放
    • コスト最適化
  • 実際の事例
    • 検索の強化
      1. 全文検索の機能はない。単純なタイトルと本文のLike検索
      2. カスタムフィールドを検索た硫黄にカスタマイズすると急激に検索が遅くなるケール
      3. コンテンツの量に比例してDBの負荷があがる
    • Connector Plugin <-> Amazon Elasticsearch

WordPress本体とプラグインの間にConnector Pluginを挟むことで
RestfulAPIで疎結合といったMicroServiceを実現

ServerLessによる開発手法の変化
  • SeverLessとは
    • ssh接続の存在しない世界での開発、テスト、デプロイ
    • サーバサイドレンダリングからクライアントサイドレンダリングへ
    • 今までサーバが存在する前提で発展してきた開発手法が一切使えなくなる
  • AMIMOTOでは
    • AMIMOTOのユーザコンソールをServerLessで開発
      • Cognito
      • User Pools
      • ID Provider
      • ユーザデータの管理をAmazonがやってくれる(UserPool)
      • リマインダー
      • 他要素認証

ユーザーデータ管理をマネージド・サービスに任せられる
リマインダーや他要素認証も実装しなくてもよい
まだプレビュー版のようだけど正式版になって導入すれば幸せになれそう

  • ServerLess周りのテクノロジーの紹介
    • ServerLess Framework
      • AWS非公認(?)の海外のサービス
    • Riot.js
      • Viewに特化したUIライブラリ
      • プリコンパイルによるレンダリング
      • 軽量でコードが書きやすい
      • APIGatewayLambdaのアプリケーションのViewとして作りやすい
    • 堀家さんがいろいろ検証している
      • http://qiita.com/horike37
    • 目的があればサーバレスが使いやすい

おわりに

AWSマネージド・サービスによるServerLess化は常に情報をキャッチアップして積極的に導入していきたいと思いました。リンクバルはサーバエンジニアを積極募集中です。興味のある方は、ご応募ください。もちろん、社内の人間と面識があるのでしたら、直接にご連絡いただいてもかまいません。