資料請求
お問い合わせ
  • tech系
9分で読める

Cloud OnAir 第8回 ～ 「最適化」を深掘する～ 速報まとめ

こちらの記事は弊社技術ブログに掲載していた内容となります。一部を除き、投稿当時の情報となりますので、紹介内容の最新情報については別途公式情報等をご参照下さい。

こんにちは。クラウドエース編集部です。

2017年10月5日より、【隔週木曜 18:00～18:45】に、Google社のエンジニアが、Google Cloud Platform の製品、サービスや導入事例等について解説する番組が始まっています。
ユーザー参加型の生放送番組となっており、視聴者からのリアルタイムQ＆Aも受け付けています！

この記事では、動画を見逃した方や、見る時間が無い方向けに、要点をかい摘まんで、クイックに紹介したいと思います。

第8回目のCloudOnAirは、クラウド化の恩恵を最大限に享受するための【最適化方法】についての解説です。
前回ではクラウド導入にあたって、Lift＆Shiftモデルの検討項目、そしてGCPを選択すべき理由について解説しました。
今回は更に踏み込み、「最適化」を深掘する内容をお届けいたします。

講師は、Google Cloud カスタマーエンジニアの村上 大河さんです。
村上さんは、昨年中のBigData処理(spotify事例)の解説に続き、二回目の出演です。

今回のテーマ: クラウド移行後の最適化方法を伝授。でも最適化ってなんですか？

単純にクラウド移行して終わりではなく、

「クラウド化の恩恵を最大限に享受するための【最適化方法】」

を考える必要があり、【最適化方法】のイメージがつかない方にわかりやすい解説になっています。
前回、安田 政弘 さんが説明した内容の深掘です。

最適化には、大きく3つのポイントがあります。(後述)

  1. managed service(マネージド サービス)
  2. auto scale(オート スケール)
  3. software defined(ソフトウェア デファインド)

アジェンダ

今回のポイントです。

  1. クラウド化のおさらい
  2. 最適化ポイント
  3. Google Cloud 事例
  4. 本日のまとめ

1.クラウド化のおさらい

最適化ポイントの紹介の前にクラウド化のおさらいとして、既存システムのクラウド化の方式について、複数あることが紹介されました。

  • クラウドへ既存システムを載せる方式の選択肢は、以下の通り多岐に渡る。
  • Lift＆Shift以外の手法については、クラウド向けにシステムの形態を変換する必要がある。

2. 最適化ポイント

最適化の2側面

  • 最適化には、次の二つの側面があります。
  • 全体の目標は、「ユーザーに早く、よいものを届ける」こと。
  • 今回は、特に運用にフォーカスしたお話になります。
  • 1.開発の最適化
    • ものを作る。たくさん、早く作る。
  • 2.運用の最適化
    作ったものを、使ってもらう。

    • 人的リソース
    • コンピューティングリソース

運用における人的コスト

システムを構成する「ソフトウェアスタック」は以下のような層で構成されているが、各々の階層について、それぞれ人間が対応することになる「管理作業」が発生する。

  • アプリケーション
    構成管理、ロールバック
  • OS
    運用管理

    • セキュリティ対策（OSアップデート）
    • バックアップ、リストア
    • 監視（正常確認、復旧）
  • ハードウェア(以降、HW)
    リソース管理

    • スケールアップ/スケールダウン
    • スケールアウト/スケールイン

→管理作業の例としては、たとえばハードウェアの負荷ピーク対応の設計がある。

リソース管理の必要性

  • ITシステムの利用される形態については、時間帯・イベント起因等、負荷の集中・閑散のばらつきを意味する、『ピーク(peak)』という概念がある。
  • リソースの設計は、ピークを想定して管理する必要がある。
  • たとえば社内システム(図中 左下のno peakのグラフ)であれば始業～昼休みまで、昼休み～終業までがピーク。

  • この場合、最大社員数を見越して、考えておく必要がある。
  • 誰も使っていないのに、高性能のサーバーが複数台でフル稼動！というのは、もったいない！
    • ピーク時を基準にしてリソースを設計すると、必然的にそうなってしまう。
    • 手動でピーク設計をするのは大変。

Webシステムへのアクセス負荷ピークの例

  • インターネット上に公開するサービスの場合、サービスの利用のピークがいつくるか、想定が難しい。
    • 基本的に負荷というのは不規則なもので、1分間あたり1人、というような規則的な負荷であることは、まず無い。
  • オンプレミス環境の場合、リソースが足りなくなったら、スペックをあげる(ScaleUp・質の向上、集中)、サーバの数を増やす(ScaleOut・量の向上、分散)とった対応を取る必要がある。
    • これまでの環境では、設備の追加・変更を準備する時間、お金といったコストが多くかかっていた。
    • 今回、これらの運用コストをクラウド化がどのように解決するのかを解説します。

マネージドサービス

マネージドサービスには、運用の移管・自動化の深度によって、IaaS ＜ PaaS ＜ SaaS の区分があります。

  • IaaS
    HWレイヤを気にせずに運用することができる。GCEが相当
  • PaaS
    OSのレイヤを気にせずに運用することができる。GAEが相当
  • SaaS
    アプリケーションの運用も気にせず、お任せできる。
    No-OPS: フルマネージド
    BigQuery/stackdriver/etc… が相当する

運用コストの最適化

  • IaaS/PaaS/SaaS それぞれのサービスの選定は、目的に合わせてサービスを組み合わせ、選定が必要。
    • 現状、GCEで運用しようと想定しているアプリケーションも、GAEに合わせて改修することで運用負荷を下げることができる。
    • 逆に、自由度が必要であればGCEを選択、等
    • サービスを細かく切り分け、部分部分でマネージドサービスを利用する、といった形態も可能

どのようにマネージドサービスを使っていくのか？

  • Lift ＆ Shift => 疎結合化 => 個々のコンポーネントをマネージドサービスへ切り替える検討
    • 最初の段階では、各コンポーネントのコミュニケーション部分(アプリケーションとデータベースの通信等)を置き換える「疎結合化」のみ実施
    • 次段階で、分離したデータベースのみをマネージド化(具体例:CloudSQL)、など。
  • 疎結合化してデータベースだけ、フルマネージドCloudSQLのみに移行するなど

マネージドサービスの課題

  • マネージドサービスは、もちろん良いことばかりではなく、課題もある。
  • ユーザー自身で管理できるレイヤーが減ることにより、障害復旧などが自分でできず、クラウドベンダ頼りとなってしまう…といった問題もある。

対応するための選択肢としては…

  • リトライ戦略
    接続先サービスでエラーが発生した場合、自動復旧に期待して、時間をおいて接続する、等の工夫をする
  • アプリケーションの作り、構造を変える
    1つの障害に引き摺られないよう、たとえばブログサービスの場合、個々のパーツをそれぞれ別のマネージドサービスに切り分けて運用する、など。

マネージドサービスの障害について

  • 障害は、数は少ないが、当然発生をゼロ件にすることはできないため、発生するものと想定した設計が必要となる。
  • 発生した場合の継続性を盛り込み、ディザスターリカバリー(DR)構成の採用でカバーしたい。

コンピューティングリソースの最適化

2つの軸があります。

  1. キャパシティ プランニング(capacity planning)
  2. ディザスター リカバリー(disaster recovery)

ピークを基準としてキャパシティを設計した場合、ピークに到達しないすべての時間軸における性能が「余剰リソース」と化してしまいます。(左下 no peakグラフ)

キャパシティプランニングにおける課題

  • リソースの余剰→オートスケーリングで解決。
    • 需要に応じて自動的にサーバ数を増減させます。
      同様の機能は他のクラウドサービスにもあるが、特にGCPはオートスケーリングが非常に速い！
    • かなり短い時間でサーバの増減が可能となっています。
    • アクセスが爆発しそうな時に前もって…といった細かな作り込みも可能。
  • オートスケーリングでは解決できない課題もあります
    • 単純にサーバを増やしても対応できないケースが該当。
      • ステートフル(stateful)な構造のアプリケーションである場合
        個々のインスタンスで処理を継続して続けるような設計のアプリケーション(ステートフル)
      • アプリの改修を含めた対応を検討
        ・アプリケーションを細かく分割、可能な部分からオートスケーリング対応させる、という手もある。
        ・少し調べてみると、案外ひとつのオプション変更でステートレスに変更できるアプリケーションもあったりします。

ディザスターリカバリにおける課題

  • オンプレミスで構成する場合、たとえば日本とアメリカに分割する構成を想定します。
  • ピーク時性能の基準で、同じ構成の『サーバ、ネットワーク、データセンター自体』等を(平常時は実際には使わなくても)アメリカ・日本の両方に用意する必要がある。
    非常に高コスト。
  • ソフトウェアデファインドの導入による解決！
    • クラウドサービスでは、ソフトウェアによりリソースを定義することで、全てを制御できる。
    • リソースを定義する仕様書(のようなもの)を用意するだけで、瞬時に環境を構築・破棄することが可能なので、低性能のマシンを待機系に用意しておき、必要になった時にスペックアップして切り替える、ということもできる。
      これを活用することで、普段は主系の日本リージョンのみで構築・運用しておき、災害発生時にアメリカリージョンに短時間で再構築する、といった使い方も可能。
      (筆者注: terraform等)

GCPを選択する理由

GCPの強みとしては、下記の3項目が挙げられます。

  1. 拡張性
    オートスケーリング
  2. マネージドサービス
    運用の最適化
  3. 最新テクノロジー

やはり何といっても一番の強みが拡張性、オートスケーリング。
その例として負荷分散サービス(Load Balancer)が紹介されていました。

  • 負荷分散をあらかじめ設計し、複数のサーバに振り分けるのは、よくある構成なのですが…
  • Googleのロードバランサーは、何と、アクセス元の地域に応じて、距離的に近いサーバへ自動的に振り分けることも簡単です。
    • 米国からアクセスしたユーザは、USリージョンのサーバへ
    • ヨーロッパからアクセスしたユーザは、Europeリージョンのサーバへ
    • シンガポールからアクセスしたユーザは、Asiaリージョンのサーバへ
  • 大量のリクエストを受け付けても、性能劣化なし。
    裏でオートスケーリングのような事をやっているようです。

Google Cloud 事例

コンデナスト・ジャパン(Conde Nast Japan) 概要

Google Cloud 事例として、コンデナスト・ジャパン様が紹介されました。
世界22の国と地域で展開しているファッション誌『VOGUE Japan』、『GQ Japan』、『WIRED Japan』等を掲げ、グローバルに事業を展開する米国「コンデナスト・パブリケーションズ」の日本法人です。

コンデナスト・ジャパン様の要件

  • 負荷の増減が激しいWebシステム。
    皆様ご存知「しいたけ占い」(VOGUE GIRL)など。
  • キーポイントは、リクエスト増加の影響によるデータベースの負荷。
  • オンプレミスでは対応が難しく、各種サービスを比較検討の結果、GCPを選択。

コンデナスト・ジャパンが GCP を選択した理由

放送の中で、Web展開を積極的に進めているコンデナスト・ジャパンは、GCPを選択した理由として下記が挙げられていました。

  1. コストパフォーマンス
    継続利用割引など
  2. Webサービスへのリクエスト急増に耐えうるスケーラビリティ
    ・Latency
    ・オートスケール
    ・インスタンス起動の所要時間
  3. ノウハウを持った認定パートナーの存在
    Grasys社　※1
  4. データ分析とシームレスな統合
    BigQuery でのデータ分析

※1：放送ではGrasys社が紹介されていましたが、筆者の所属するクラウドエース株式会社も、Googleのプレミアサービスパートナーです！
https://cloud.google.com/partners/directory/?hl=ja

Q＆A

今回はQ＆Aのご紹介はありませんでした。

まとめ

「良いものを、早く出していく」を実現する。
そのための運用の最適化。実現するには、クラウドならではの機能を使いましょう。

  1. managed service(マネージド サービス)
  2. auto scale(オート スケール)
  3. software defined(ソフトウェア デファインド)

( Dev ) + ( Ops ) + ( Security ) : 開発 + 運用 + セキュリティ。この三つを上手に使いこなす。

最後にひとこと

以上が、「CloudOnAir 第8回 クラウド移行後の最適化方法を伝授。でも最適化ってなんですか？」のご紹介となります。

次回も村上 大河 さんが講師を続投し、「開発・運用・セキュリティ」の三本柱のうちの「セキュリティ」。
テーマは『クラウド移行でここは外せない絶対条件、Google Cloud Platform のセキュリティについて全て話します！』を予定しております。
まとめでも言及がありました通り、次々回は「開発」を取り上げられる予定です。

リアルタイムに講師への質問投稿もできる、生放送視聴については、下記URLから、是非！お申し込みください。
https://cloudplatformonline.com/onair-japan.html

参考リンク

YouTube視聴

Cloud OnAirの放送は、今回分含め、バックナンバーも全てYouTubeで視聴できます。
スライドと合わせて進行する解説を、是非ご覧ください！
YouTube URL：https://www.YouTube.com/watch?time_continue=404&v=LUjhZyXNFJE

SlideShare

今回の動画で説明に使用されたスライドについても、SlideShareでいつでも閲覧可能です。
登場した用語について振り返りたい、用語同士の関係性を確認したい等、大変参考になります！
スライドURL：https://www.slideshare.net/GoogleCloudPlatformJP?utm_campaign=profiletracking&utm_medium=sssite&utm_source=ssslideview

それでは、次回も2/22(木) 18:00にお会いしましょう。

この記事を共有する

合わせて読みたい

↑