スタートアップ企業向けインフラ運用入門の最近の記事

スタートアップ企業向けインフラ運用入門

スタートアップ企業向けインフラ運用入門(4):システム拡張の具体例

|

システムをリリースして無事運用に乗った後も、様々な要因によりシステムを拡張する必要が出てきます。今回は、システム拡張の要因、及び基本的なシステム拡張の方法を具体例を挙げつつ説明していきます。

初めに

これまで4回に渡り、インフラ運用に関する入門的な記事を書いてきました。それらの内容を実施して、システムが安定運用に乗ってきたと仮定します。業務系のシステムであれば、そこでインフラ担当の仕事は大体終わりとなり、オペレーターなどに主要な業務を引き継ぐことになると思います。それに対してRettyのようなWebサービスの場合は、システムが軌道に乗った後も継続的なシステム拡張が発生することが一般的です。

本記事では、まずどのような事をきっかけ・要因としてシステム拡張が必要になるのかについて説明します。次に、Rettyのシステム構成を簡単に説明し、システム拡張が必要となる各種要因に対して、どのような方針で拡張を実施していけばよいかを、Rettyでの実例を元に説明します。最後に、システム拡張の際の具体的なtips、注意点についても述べていきます。

システム拡張のきっかけとなる事象

まずは、どのような事が契機となって、システム拡張が必要になるかについて説明します。

アクセス数の増加

システムへのアクセスが増えると、現状でのシステム構成では捌ききれなくなり、一般的にはシステムの増強が必要になります。

アクセス数の増加原因としては、以下の2通りが存在します。

  • 自然増
  • 一時的な増加

「自然増」に関しては、以前説明したログ・メトリクスの収集を行なっていれば、いつくらいに処理能力の限界に達するかが分かるため、対策は比較的容易です[1]

それに対し「一時的な増加」には、アクセスがどのくらい増加するかを予測しづらいという特徴があります。

また一時的な増加は、増加のタイミングがあらかじめ分かっているものとそうでないものがあります。前者の例としては、「メディアでのプレスリリース掲載」「テレビ番組での紹介」などが挙げられます。後者の例としては、影響力のある人がブログで紹介したりTwitterでつぶやいたり、特にサービス運営側への取材もなく、メディアが掲載してくれる、といったものが挙げられます。

[1]本連載の記事「ログ・メトリクスの収集」を参照。

データ量の増加

データ量の増加もシステム拡張要因の一つです。Rettyのようにユーザー登録してユーザーがコンテンツを投稿するようなサービスの場合、以下のようなデータが増えていきます。

  • ユーザーデータ
  • 投稿データ
  • ユーザーの行動履歴

サービスの種類によって、増えるデータの種類はこれらとは異なることもありますが、いずれにしてもサービス提供期間が長くなるに連れて、システム内のデータは増えていきます。

機能追加

Webサービスは一旦リリースしたらそれで終わりではありません。随時、機能追加や修正を行うのが常です。それに伴い、基本的にはデータ量が増加していきます。

Rettyの例で言うと、リリース当初は投稿につき写真が1枚しかアップロードできませんでした。しかし、現在では10枚までアップロードできるようになっています。また「人気の投稿」を表示するために、各投稿に対して「行きたい」をクリックした人数を、定期ジョブで集計してDBに保存しています。これらにともない、システム内部に保存しているデータ量も多くなっています。

スタートアップ企業向けインフラ運用入門

スタートアップ企業向けインフラ運用入門(3):バックアップとリカバリー(その2)

|

前回はバックアップ・リカバリーの基本的な知識、設計のポイントなどについて説明しました。今回は、バックアップ・リカバリーの具体的な方法について、バックアップ対象別に実例を挙げながら説明していきます。

はじめに

前回、リスク管理という観点からバックアップ・リカバリーの対象や手法等の基本知識、さらにバックアップが対処するリスク事象について説明しました。

今回は、システムファイル、Webコンテンツ、データベースなどのバックアップ対象ごとに、代表的なバックアップ・リカバリー方法について、その長所や短所をあわせて説明します。

スタートアップ企業向けインフラ運用入門

スタートアップ企業向けインフラ運用入門(3):バックアップとリカバリー(その1)

|

本記事では、初めに「リスク管理」という観点から「バックアップ」を見て、バックアップが対処するリスク、次にそのリスクへの対処法としてバックアップの設計の概要について述べます。その後、バックアップの種類、それらのトレードオフ、バックアップ対象といったバックアップの基本事項について説明し、最後にリスク事象である「データ消失」の具体例を原因別に挙げて説明します。 次回の記事では、具体的なバックアップ及びリカバリー方法について説明していきます。 なお、本記事内では適宜用語の説明などは行いますが、読者の方は運用関連の基本的な用語などに関してある程度の知識があることを前提とします。

バックアップ及びリカバリーとリスク管理

過去2回の記事で、「監視」及び「ログ・メトリクス」について扱ってきました。今回扱う「バックアップ」と「リカバリー」も、これらの記事で何度か話題に挙げた「リスク管理」という大きな枠組みの中に位置づけられるでしょう。

スタートアップ企業向けインフラ運用入門

スタートアップ企業向けインフラ運用入門(2):ログ・メトリクスの収集

|

システム・サービスに関するログ・各種情報を取得する事により、トラブルシューティング、パフォーマンスチューニングのみならず、ビジネス上の成果の確認、UIの改善等にも役立ちます。ただ、闇雲に情報を取得しても、効果は上がらず労力ばかりがかかってしまいます。本記事ではログ・メトリクスの収集の目的を明らかにし、その為に必要な点を実例を挙げながら説明していきます。

「ログ」取得の目的

Retty開発担当の鹿島です。Webサービスに限らず、ITのシステムを運用していれば、何らかの形で「ログ」の取得・保存をしている事かと思います。そもそも、それらは何のために保存されているのでしょうか。まずは、「ログ」を保存する目的を明らかにし、その観点から各種の「ログ」について見ていきたいと思います。

開発や運用経験のある方であれば、

「ログにxxxに関する情報が出ていれば、障害解決がスムーズなのに......」

とか、あるいは逆に

「ログが大量過ぎて重要な情報が探しにくい!」

などと思った経験があると思います。ログを取得する目的を明確にする事により、こうした事の大半は避けられると考えています。

log_metrics.png

ログを取得する目的は色々ありますが、大雑把に以下の4つに分類できると思います。

  • 障害発生時のトラブルシューティング
  • パフォーマンス改善
  • ビジネス上の成果の確認
  • UIの改善

今回の記事では、この中から主に最初の2つを扱います。なお、本記事内で言う「ログ」は、いわゆるシステム関連のログだけでなく各種指標・メトリクスを含みます。詳しくは後ほど説明します。

障害発生時のトラブルシューティング

さて、ログを取得する理由として一番最初に思い当たるのは、障害発生時のトラブルシューティングだと思います。システムが応答しない、予期しない異常な動作をするなどの障害が起きた際に、ログを参照することによって以下のような事実が特定されると期待されます。

  • 障害発生日時
  • 障害発生箇所
  • 障害の原因
  • 障害による影響範囲

逆に言うと、これらを特定できるようにログを取得する必要があるということです。

log2.png

スタートアップ企業向けインフラ運用入門

スタートアップ企業向けインフラ運用入門(1):監視

|

スタートアップ企業等の少人数チームの場合、専任のシステム運用担当がいることは稀だと思います。本記事では、そうした少人数チームの開発兼運用担当者を主な対象として、システム運用の重要な要素である「システム稼働状況の確認、障害対応」を省力化するための方法の一つとして「システムの監視」の方法について説明します。

少人数チームでのシステム運用

Retty開発担当の鹿島です。第1回で少し紹介しましたが、RettyはWebサイト、iPhoneアプリ、Androidアプリの計3プラットフォームを、3人+αの開発者で開発を進めています。私は主にWebサイトの開発とインフラ全般を担当しているのですが、Webサイトの開発がメインのため、インフラ構築・運用に割ける時間はそれほど多くありません。

おそらく世間の小規模チームの大半では、我々と同様に専任の担当者がいないと思われます。今回の記事はそうしたスタートアップ企業など、小規模チームの開発者兼インフラ担当者を主な対象として、極力手間をかけずにインフラ周りの運用を行うためのノウハウを紹介していきます。

まずは最初にインフラ構築・運用に関する基本的な方針を説明し、次にインフラ運用の重要な要素である監視に関して説明します。その後、実例を交えつつ監視項目について説明します。

本記事の内容はIaaSの使用を前提としていますが、PaaSや自前でサーバーを持っている場合にもある程度は当てはまるかと思います。

また、本記事は過去の記事と同様、Webサービスを構築している・しようと考えている方を対象としています。従って、業務系システムとは事情が異なる場合が多いですし、マネージメントやITILの話などは出て来ません。

なお、筆者自身の経歴は、開発が半分、残りは運用、技術コンサル等なので、いわゆるインフラ屋さんではありません。インフラ専門の方からのご意見なども頂ければ幸いです。

アーカイブ