システム構築デザインのおさらい

今週のブログは、まだまだ何かと初級レベルの岩石(Lv. 15)が担当です。

ここ数年、システム構築の設計や構築などについて支援を依頼されることが多くなりました。
ほとんどはIaaSのクラウドでのシステム構築の場面での支援です。

基本的には、運用を意識した構築が望ましいと考えていますが、そのような構築の手法については、従来からベストプラクティスとして言われ続けている手法がほとんどです。
私独自のアイデアというわけでは無いですが、自分へも含めておさらいとして記事に残そうと思います。

構成

クラウドの場合、使い捨てものと大切に使い続けるものを分けて考えています。
何より大事にしたいのは、保存された情報(データ)です。
サーバインスタンスは基本いつか止まるものと考えて、代替手段や再構築が簡単に行えるようにしておくことが大事です。

AWSのEC2などでは、ファイルなどが保存されるボリュームは、サーバが動作するインスタンスのボリュームとは別に用意しマウントして構築します。
例えばRedmineの場合、デフォルトではアプリケーションディレクトリ配下のfilesディレクトリに添付ファイルが保存されます。またアプリケーションの動作ログはアプリケーションディレクトリ配下のlogディレクトリに保存されます。
この場合、Ruby on Railsのアプリケーションをサーバが動作するインスタンスのボリュームとは別のボリュームに保存することで、サーバインスタンスの障害から情報を守るようにしています。

また特に無停止を要求されるシステムでは、ロードバランシングや冗長化は必須なのですが、一つ一つのインスタンスの性能を時間をかけてじっくり選定するより、足りなきゃ増やす・余れば削除する考え方が適用できるようにシステムを考えておくと、構築当初のスペックに悩まずに済み、また運用中に柔軟にスペックの変更もできます。
上位にリバースプロキシサーバを配置し、その下位にアプリケーションが動作する全く同じ設定のサーバを複数配置し負荷処理を調整する方式が一般的です。

OS管理


http://www.ubuntu.com/

システムでOSは統一するのが原則です。
OSはメージャーバージョンが変わると、別物になります。ある程度互換性は維持されますが、管理技術など刷新されることも多く、注意が必要です。

ubuntuでは長らくプロセス起動管理をUpstartで行ってましたが、昨年発表されたバージョンからはSystemdに変更になりました。
RedHat Enterprise Linux/CentOSでは、5ではSysVinit、6ではUpstart、7ではSystemdが採用されています。

運用のスタッフやチームが複数のシステムの運用をすることを考えると、そのシステムだけでなく組織で統一しておいたほうが良いですよね。
しかしながら、導入時期、サポートの期間また必要とするパッケージの機能などの事情でOSやバージョンが限定される場合もあると思います。
大事な作業や設定をいかに標準化するかが重要ですね。

アクセス制限


Photo by Jessica Paterson

サーバへのコンソールログインにはsshを使用します。
(悪意を持った)sshログイン試行は、サーバをインターネットに接続するとすぐに行われるようになります。


sshログイン試行の実例。中国とフランスから。

わざわざ危険な状況にさらすこともありませんので、事情のない限りsshのログイン元のIPアドレスは限定するようにしています。また特定することができない場合は、根本的な解決ではないのですが、sshdの待ち受けポートを変更するようにしています。

そして、sshログインについてはrootアカウントでのログインは禁止しています。
後述しますが管理作業のログを残すためと仮にログイン試行が成功した場合に備えるためです。
(まぁ、入られちゃったらその時点でアウトですけどね)
そして認証は公開鍵認証を必須にしています。

アカウント管理

異動などによる権限の付与や削除をフレキシブルに行えるようにするために、共有アカウントは避け、各個人個人のアカウントで運用を行うようにしています。
またシステムにデフォルトで設けられているアカウントについては、特例を設けないようにするため、使用できないようにしています。

あとLinuxではroot(管理者アカウント)でログインすると操作が記録されません。
可能な限り sudo を用いて管理操作のログを残すようにしています。

ログ管理

上記のアカウント管理にもログの内容を書きましたが、アプリケーションやサーバサービスその他にも多くのログを出力することができます。
できるだけ多くの種類のログを長期間取得したいですが、容量の問題でサービスに影響を及ぼしてはいけません。
また多くのサーバ等から構成されるシステムで、ログがあちこちに点在しているのも管理が大変です。

コスト面で問題がなければ、ログサーバを設け、ログを一箇所に集約するようにしています

などの面で効果がありますし、ログの閲覧用のアプリを作成したら、サーバにログインすることなく、必要な者が必要なログを見ることができます。

以前は rsyslog でログを集約していましたが、最近では Fluentd を使うようになりました。

Fluentd

作業記録

構築後の資料作成や作業後の動作異変の調査などのために、作業時は script コマンドを使って作業のログを記録しています。
出力されたファイルは決して見やすい物ではないですが、有効な資料として残り重宝します。

ソフトウェア管理

サーバで動作させるアプリケーションは暗号化通信やデータベース関係などのライブラリが必要となります。 こういったライブラリなどのソフトウェアも機能改善やバグ修正などでバージョンアップを繰り返していきます。
またアプリケーションを動作させるプログラミング言語もサポート期間が指定されていたり、アプリケーション側で版数を指定されていたりします。

運用を考えるとバージョンアップをより実施しやすくしておくことが大事だと思われます。
一般的にはOSで準備されている標準のリポジトリを使用して導入しています。
脆弱性対策などのための更新も容易いため、速やかな適用が行えます。

ただし、言語やミドルウェアなどで最新版がOS提供のリポジトリで提供されていない場合があります。
最新の機能が必要な場合、ソフトウェア開発元が、OSに対応できるライブラリを提供している場合もあります。
nginx などは開発元から各OSに向けたリポジトリを公開していますので、最新版が使いやすく、助かっています。

nginx

アプリケーション管理

実際にサービスを提供するアプリケーションも様々な理由で更新を繰り返します。
毎回設定ファイル等を維持しつつダウンロードしたものを導入するのは効率が悪いです。
自社で作成されたアプリケーションのソースコードは全てリポジトリで管理しています。
開発に向けた版数管理や課題管理だけでなく、デプロイの場面でも GitMercurial などのコマンドで更新し、簡単にバージョンアップを実施しています。

バックアップ

業務用のサーバでは、バックアップは必須です。
バックアップの目的はリストアです。復元できないバックアップは意味を持ちません。
バックアップデータがプロプライエタリなツール専用のフォーマットの場合、ツールをインストールするまでデータを利用することができません。
私がよく使っていたのが Amanda です。バックアップデータの形式を指定できるのですが、tarやgz形式など標準的なコマンドで解凍できる形式で出力されるため、万一ツールが使用できない場面でもファイルを取り出すことが可能です。

Amanda Network Backup

実際にバックアップを実行すると、長時間にわたって高い負荷がかかった状態になります。
このため、バックアップを実行するコマンドには niceionice で優先順位値を付与し、提供するサービスへの影響を極力減らすようにしています。

なお、仮想サーバやクラウドサーバであれば、スナップショットでのバックアップも使っています。復元が早くより使いやすいバックアップ方法だと思います。

監視

監視には大きく分けて「リソース監視」と「死活監視」があります。

リソース監視は、稼働状況が保有している資源(CPUのスペックやメモリの量、HDDの容量など)で十分かどうかを確認するために行います。
死活監視はサーバが停止していないか、サービスを提供しているプログラムが止まっていないかを監視します。
弊社では以前紹介した通り ZABBIXMunin を併用しています。

Zabbix

クラウドでは専用のインターフェースをサービスとして提供している物もあります。AWSでは CloudWatch というサービスで監視ができます。
AWSだけで運用を行う場合はCloudWatchで監視を行うのも良いと思います。

最後に

いくつか思うところを書き出してみました。
セキュアOSの採用や運用時の決め事など、他にも様々なトライがあるのですが、少々長くなりましたのでそれはまたの機会に。

失敗からの学びを皆で共有し、運用しやすいシステムの構築を考えていきたいと思ってます。

ファーエンドテクノロジーからのお知らせ(2024/03/27更新)
2024年4月14日 オライリー本の全冊公開日のお知らせ(もくもく勉強会も同時開催)
ファーエンドテクノロジーが所蔵するオライリー本(全冊)公開日のご案内です。公開日には「もくもく勉強会」も同時開催します。
My Redmine スタンダードプランおよびAdminサポートデスクプランの料金改定のお知らせ【2024年4月ご利用分より】
2024年4月ご利用分より、My Redmine スタンダードプラン(民間企業・個人向け及び官公庁向け)とAdminサポートデスクプランの料金を改定いたします。
My Subversion 一部のプラン・料金改定のお知らせ【2024年4月ご利用分より】
2024年4月ご利用分より、My Redmine スタンダードプラン(民間企業・個人向け及び官公庁向け)とAdminサポートデスクプランの料金を改定いたします。
My Subversion ストレージ容量増量のお知らせ(一部プランを除く)
My Subversionではミディアムプラン以上の各プランのストレージ容量を増量します。
Redmineの最新情報をメールでお知らせする「Redmine News」配信中
新バージョンやセキュリティ修正のリリース情報、そのほか最新情報を迅速にお届け