【システムを構築するときに気をつける10のこと】に行ってきました

【サポーターズ勉強会】システムを構築するときに気をつける10のこと

https://supporterzcolab.com/event/233/

に行ってきたので、その時のレポート

資料

基本的に、このスライドに書かれていることをなぞって講演していただいたので

このスライドをみればだいたいイベントの内容が分かります。

ただ、口頭で説明のあった箇所などはメモをとっていたので

下記に記載します。

まえおき前提

web業界において、スピード重視でサービスリリースするような開発

アジャイル開発などを対象に今回の講演をします。

登壇者の方がよく思うことが、

サーバーサイドエンジニアから受ける質問として

「この機能作りたいんですけど気をつけることありますか?」

と聞かれることがあるのだが、気をつけることはいっぱいある。

だが、書籍とかで気をつけるべきことの情報は見つけにくい。

それで、今回ざっくり説明をしていただける。

安定稼働にはコストとリソースがかかる

設計とかで、結構時間がかかる。

オンプレで動いてたものをクラウドで動かすとかだと、

どのくらいの費用がかかるのか、どういう設計にするのが良いのかが検証してみないとわからない。

例えば、クラウド環境で冗長化するとして、

マシンを1台で動かしてたものを2台にするとかだったら、2倍料金がかかる。

1台が死んだら2台目に切り替わるという仕組み作りの検証もしておかないといけない。

運用体制コスト

誰が通知を受けて、、誰がエスカレーションして誰が対応するのか

とかとかのマニュアルが必要。

ディザスタリカバリを考え、日頃から訓練する。

オペミスとかでデータが消失したときの対策

これは結構難しい。

設計はしたけど、日頃訓練しておかないと

いざ障害が起こったときに、うまく動けないことがある。

擬似的に障害発生させて訓練しよう

システムが落ちたという報告を誰が誰にエスカレーションしないといけないのかを決めておく

例えば、上司に報告して、上司はお客さんに報告するとか。

モニタリングのメトリクスは細かく取る

こういうのを細かくとっておくと、

障害が発生したときとか、スケールするときに情報になる。

ただし、メトリクスをとりすぎると逆にマシン負荷になるので注意が必要

代表的なメトリクスはグラフにしたりしておく

また、そのメトリクスの意味を理解しておく

query/sec というメトリクスってなんのクエリなんだっけ?」とか。

システム全体がスケールできる

ネットワークのスループット

例えばデータセンターだったら、外から入って行くるのが1本だったら、それに耐えられるのかとか。

外部連携

例えばBIツールを使っているときも、外との連携でスケールできるんだっけとか。

設計/選定した技術には責任を持つ

使ったけどちょっと違ったかなというときは

ちゃんと自分で負債を返していかないといけない。

技術選定が間違っていたとかいうこともあるが

それをちゃんと返して行こう

そのためにも、採用した技術には一番詳しくなっておこう。

仕様やデータ構造の変更は必ず発生する

仕様とか技術は変わっていくので

変わってもいいように設計を考えておきましょう。

データの保管場所は塾考する

例えば、クラウドからオンプレに持って行きたいとなったときに

データ量が多いと、転送時間に時間がすごくかかるので気をつけないといけない。

データレイクというのが最近注目されている

データレイクとは、1箇所に全てのデータを集めて使えるようにしましょうという考え方。

セキュリティ対策は必要だが、コストと時間がかかる

権限管理はすごい大変

ここはちゃんと設計しておかないと行けない。

権限の設計が必要

 → しかも、変更が入るので、柔軟な設計が必要

誰が管理して、だれが付与して・・・

転職とか退職とか、人の入れ替わりがあって、権限の管理が大変

クラウドを信頼しすぎない

クラウドはだいぶ安定・安心できるが、100%の安定では決してない。

EC2の場合、メンテナンスのために強制的にシャットダウンされることがある。

だが、EC2の中でvmが動いていて、vmの中のメモリでアプリケーションが動いていて、

シャットダウンさせるには、メモリにのっているデータを退避させないといけないとかの状況の場合もある。

だが、シャットダウン日は10日後に迫っていてつらい。。みたいな状況もある。

謎のサービスレベルの低下

AWSに質問した。

回答は、他で使われているインスタンスの負荷で、それに引っ張られてますとかの回答がきた。

結局、言いたかったこと

優先順位を決めよう

セキュリティが重要だったらそれからやろう。

スケールが大事だったらそれからやろう。

全部やれるにこしたことはないが、時間もないので。

Q & A

Q.どんなメトリクスで区切るとかコツはある?

A.僕(登壇者の方)の場合は低レイテンシーが求められているので、

 1msec, 4msec, 10msec, …. とかで返したクエリとかでメトリクスを切っている

 そのときのメモリの使用量とかを分析できるので、目的別でメトリクスを区切るようにしている。

 

Q. おすすめのメトリクスツールは?導入が簡単とか。

A. saasサービス

   New Relicとか。

   Datadogをリソースの管理で使っている。

   Datadogは楽。

   どちらも外部サービスなんで、アラート飛んできたらどこにいても見れるとかのメリットはある

   ただし、セキュリティに厳しい会社だとそれができないかも

   zabbixとかも、サポートが手厚い。

   

Q. 外部のメトリクスサービスを使うのではなく、逆に自分たちで作らないといけないときの条件は?

A. KVSとか、高速にクエリを処理したいときとか。

 AirSpace?というKVSと使っているがDatadogとかだと対応していなので

 分析用のシェルを自分でつくって、それをDatadogに投げるとかのことは自分でしないといけない。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です