【勉強会】システム構築で気をつける10のこと
外部の勉強会に参加したので、I/O
前提
- スピード重視でサービスリリースをするような開発前提
- アジャイル開発のような短期間で動くソフトウェアをリリ＝すして行く開発スタイルを想定
なぜこの話をするのか
- アプリケーションエンジニアからよく聞かれる
- 書籍などの情報では身につけにくい
- 10以上のシステムを構築してきた経験
システム構築するときに気をつける10のこと
1. 安定稼働にはコストとリソースがかかる
安定の要素とは
可用性が高い
- シングルポイントがない
- エラーハンドリングがサービスレベルでできている
耐障害性が高い
- アプリケーションの冪等性が担保
- システムに一貫性
柔軟性が高い
- 密結合がない
- 機能拡張しやすい設計
安定化のためのコスト
アプリ/インフラの設計 検証コスト
- 設計段階で色々なケースを調べ、実際に動かす時間
冗長化のためのコスト
- 1台でも稼働可能であるが、2台立てる
- 冗長化を実現するための仕組みを作る
運用体制を整えるコスト
- Change Managementのフロー確率 -> 責任分岐を明確に
- 運用する人のコスト -> アラートを受け取る人の採用
- 運用体制を作るコスト -> 運用設計にも時間が必要
2. ディザスタリカバリを考え日頃から訓練する
ディザスタリカバリとは
- 災害からのリカバリ
災害などの被害から回復措置を考える
- ネットワーク障害が発生した場合、何をする必要があるか
- クラウドサービスに障害が発生した場合の対策
- データ消失した場合のバックアップ/リストア対策
日頃からFire drillを行う
fire drillとは
下層のディザスタリカバリの状況を作成して、設定パフォーマンスを評価することによって リソースのフェールオーバーの信頼性をテストする方法
実際に擬似障害を発生させて訓練する
- 手順やリカバリ方法を明確にしておく
- 誰が対応する、誰に連絡/報告するかを決めておく
3. モニタリングのメトリクスは細かく取得する
リソースモニタリングは必須
CPU Memory usage Disk usage Inode usage Network throughput
サービスモニタリングも行う
query per second request/response time
注意すべき点
メトリクス取得は不可になる場合もある モニタリングツールが負荷になり、サービス影響が発生する
メトリクスを取りすぎて有事の時に何を見たら良いのかわからない
代表的なメトリクスはダッシュボードにしておく メトリクスの意味を理解しておく(何を表す値だったっけ？とならないために)
4. システム全体がスケールできる
システムは肥大化していく
目につく以外のところもスケール必要
DBユーザ/コネクション数 ネットワークスループット 外部連携するシステム
処理するデータ
- データベースの肥大化
- バックアップデータの肥大化
- 分析対象の拡大
5. 設計/選定した技術には責任を持つ
導入した技術は一番詳しくなる
導入したけど自社システムに向いてなかった
- サーバーレス
- マイクロサービス
自分で対応、負債回収をする
- ミスや動かしてみないことは多々あるので責任を持って面倒を見ていく心構えが大切
6. 仕様やデータ構造の変化は必ず発生する
世の中は変わる、時代も変わる
普遍的な技術でも変わる可能性がある
暗号化方式: SHA1 -> SHA2 ネットワークのプロトコル: http -> WebSocket クライアント: ガラケー -> スマホ データベース: リレーショナルDB -> KVS, NewSQL フォーマット: JSON Protocol Buffers
7. データの保管場所は熟考する
データの保管は重要
- データが肥大化することで転送量、転送時間が増えてコストが上がる
- データは使いたい時に低コストで使える状態にする
- データの維持も大変
- データレイクを作るのが理想(Amazon S3, Coogle Cloud Strage, HFDSなど
8. データは想定より多くなる
データは肥大化する
世の中が扱うデータが増える
システム/機能が追加されてデータが増える
- ブラウザからのアクセス: → アプリ、様々なデバイス(Amazon Echo)からのアクセス
9. セキュリティ対策は必要だが、コストと時間がかかる
セキュリティ対策は複雑で豊富
- ネットワークセキュリティ
- データベースのアクセス権
- コンピュートの権限
- アプリケーションの権限
- ログなどシステムデータのアクセス権限
- クラウドサービス(SaaS)の権限
- データセンターのセキュリティ対策
権限管理と運用を考える
権限の種類の設定が必要
権限の運用と監査にはコストがかかる
- ユーザが増える減る
- アクセス元が増える: BIツールからアクセスした
- 誰が管理してるかなどの把握
10. クラウドを信頼しすぎない
クラウドは高信頼であるが、100%落ちないわけではない
- Service Level Agreement(SLA)の確認
- 定期メンテナンスの罠(メンテでサービス停止、AWS Redshift, Google CloudSQLなど)
- クラウド都合のシャットダウン(AWS EC2)
- 謎のサービスレベルの低下(うるさい隣人問題)
結論
システム構築をする時には、目的と優先順位を明確にシステム構築する
