絶対完全無料ツールの紹介

エンジニア目線のブログです

トップ > ネットワーク > #10 Linuxとネットワークのベストプラクティス

#10 Linuxとネットワークのベストプラクティス

ネットワーク

youtu.be

「DBのベストプラクティス」の動画でも説明したようにLinuxでも
基本的にはLinux特有の機能はできる限り抑えて
できる限り誰もが知っているPHPやPythonのサーバーサイドプログラミングで
機能開発すべきです。

なので、Linuxですべき機能はあっても
デプロイ、ログ収集、監視設定
ぐらいかと思います。

iptablesに関してもできる限り最低限の設定で済ませるべきです。
アクセス元のIPをブロックするなどは、PHP,Goなどで制御して
iptablesではプライベートネットワークを許し、webアクセスを許すといった
最低限の設定を一律全てのサーバーにすべきです。

例えば、Linuxに詳しい人はiptablesでポートフォワーディングできるので、
HTTPアクセスを別のサーバーに転送することも可能ですが、そうしてしまうと
ほとんどの人が知らない中そんな設定をされると現場が大混乱してしまいます。

クラウドのベンダー選定ですが、「AWSエンジニアの悲劇」でも取り上げたように
AWSを使うとろくなことないので、AWSは使わないようにしましょう。
その他のGCP,Azureも同じく高いのでやめておきましょう

さくらの専用サーバーはコンソール画面のログインの2段階認証機能があるので、
セキュリティが高いのとコンソール画面がターミナルと同じように使えるので
おすすめです。

Kagoyaに関してはさくらインターネットは北海道に集中しているので
ディザスタリカバリ DR の事を考えて開発用、DRバックアップ用
として考えておくといいかと思います。ただし２段階認証やコンソールからの
ターミナルが使いにくい所がマイナスです。

Time4VPSはリトアニアの激安VPSベンダーです。
安いさくらVPSのさらに３分の１ぐらいの値段です。
ただ、サーバーがリトアニアで地理的に遠いのでSSH接続は若干遅いです。
２段階認証、ブラウザからのターミナル、
プライベートネットワークもサポートしているので、
デメリットはなく素晴らしいサービスですが、
実績がないので大規模な本番のシステムに組み込むのは
少し躊躇します。
Kagoyaと同じようにディザスタリカバリ DR や開発用であればまず問題ないと思います。

以前の大規模システムの構築の時はさくらVPSを多めで
スケールアップよりもスケールアウトを心がけて
さくらの専用サーバは少なめに設計しましたが、サーバーが増えると
監視などの管理が大変になってくるのと、同じサーバーに
複数のサービスを立てたほうがリソース消費は少なく済むため
さくらの専用サーバでネットワーク構築することが望ましいかと思います。

なぜスケールアップよりスケールアウトを心がけていたかというと
スケールアップに頼るとどうしてもサーバーのスペックがどんどん上がってしまい
高額になってしまいますし、サーバーのスケールアップには限界があるので、
その限界に来た時には手におえない状態になる可能性があります。

例えばDBのスロークエリーが多くなってきたので、メモリを増設してDBのキャッシュ
に頼るとその一時しのぎであれば解決できますが、
DBのキャッシュもSQLのパターンが増えれば
すぐにその増設したメモリでは足りなくなってきてしまうので、
根本的なDBの設計とSQLを見直さないといけません。

しかし、その時点で時既に遅しで深みにハマってしまっているので
どうしようもなくなっている現場もありました。

なので、いつでもスケールアウトできる仕組みで
専用サーバーで構築するのがベストかと思います。

プライベートネットワークを構築する前提で踏み台サーバーの設定を
説明します。

iptables,linuxアカウントの設定のみ踏み台サーバーの設定が違うので
先にこの２つの説明をしていきます。
iptablesの設定は
プライベートネットワークは全許可
WEBも許可
NTPやICMP,PING、ループバックも許可

踏み台サーバーの時のみsshのポートを許可する設定をします。
セキュリティのため念には念を入れsshのポートは22から
違うポートの39870にしています。39870は決めの問題で適当な番号を
指定すればいいかと思います。

踏み台サーバー以外のサーバーではSSHのポートはpublic向けには
開放しないので、設定なしでOKです。

Linuxのアカウントですが、踏み台サーバーのみ各スタッフ用の
アカウントを作成して、各部門もしくはチームのグループを踏み台サーバーで
あらかじめ用意しておいて、所属しているグループにアカウントを追加します。

そうする事で踏み台サーバー以外のサーバーはスタッフのアカウントは追加せず
engineerなどのチーム単位をLinuxのアカウントとして登録するだけで済みます。

以前は全てのサーバーにスタッフ分、エンジニアの数をLinuxのアカウント作成
していましたが、スタッフが入退職するたびに全てのサーバーに入って
アカウントの追加、削除が必要でコストがかかり大変でした。

踏み台サーバーだけにスタッフのアカウントを用意すれば、入退職があった場合も
踏み台サーバーだけを変更すればいいです。

サーバーの追加の時もチーム単位のアカウントのみの作成で済むので、楽できます。

オペレータなどのアカウントはほとんどのケースで不要で、サーバーから生成される
CSVなどをSFTPで取得する時とかに必要なぐらいです。

なので、だいたいのサーバーはエンジニアが使う共有アカウント１つで十分かと思います。
このようなネットワーク構成であれば運用コストもかからず済みます。

セキュリティリスクが高くなるのではと考える人もいるかもですが、
踏み台経由でしかサーバーにアクセスできないようにすれば、作業ログも取得できて
監視できるので、セキュリティレベルも変わらないと思います。

１回踏み台にログインした時のログはbash_historyにログが保存され、
ポートフォワーディングの場合は/var/log/secureにログが保存されます。
bash_historyの履歴変更できないようにするにはchattrを使えば防げます。

全サーバー共通の設定をざっくり解説していきます。

linux userはあらかじめ生成バッチなどを用意してたほうが
運用が楽かと思います。
engineerというグループにこのアカウントをアサインしています。
ssh keyの空ファイル生成までの設定をしています。

visudoの設定はCRITICALのコマンドを定義して
グループのengineerにアサインします。
CRITICALのコマンド以外は何でもOKにしています。

アカウントとvisudoはrootで行う必要があるので、管理者が
設定を行う必要がありますが、
これ以降は一般Linuxユーザーでもできるので、管理者以外の
エンジニアに任せたほうがいいかと思います。

sshの設定でポート番号は踏み台のみ設定変更で問題ないと思います。
それ以下の設定はrootでのSSHログインを禁止
パスワードログインを禁止
等の設定をしています。

FirewalldとSELinuxの無効化の設定します。

hostnamectl set-hostname ＜HOSTNAME＞
でホストネームを変更します。

これらの設定が全サーバーにインストールしてからの必須の設定です。
この必須の設定ドキュメントはgitでバージョン管理すればいいかと思います。

PHP,Go,MySQL,PostgreSQL,nginxなどは各サービスの担当エンジニアに
任せればいいかと思います。

サーバーのスペックはさくらの専用サーバーで現在一番安いサーバーで
４コア、メモリ８GB、SSD５００GBのサーバーを標準にすればいいかと思います。

大量アクセスが想定されるロードバランサーに使う場合は回線の
帯域幅を上げるといった設計が必要になるかと思います。

画像とDBのアーカイブ、バックアップサーバーについて。
どれだけ大きいサービスでも
DBのフルダンプでだいたい最大で２０GBぐらいかと思います。

それ以上になるとログ系のデータが含まれていたり、
メンテナンスで物理削除していないとか、アーカイブ化していないとかの
設計ミスかと思います。

どんな大きなサービスでもDBサーバーが５，６つぐらいかと思いますので
１００GBぐらいがDBのバックアップで充分かと思います。

世代管理もしてても今まで古い世代のリストアをしたことがないので、
最新のバックアップのみで問題ないかと思います。

なので先程の標準のサーバーを選択しておけばデータのバックアップ兼
サーバーの物理障害兼、ステージングサーバーとして扱えるかと思います。

画像に関してはサービスによって大きく変わってくるので、相当数
必要な場合は専用サーバーのディスクをあらかじめ多めのHDDにしておく
なりの対処が必要です。

AIの画像解析サーバーが必要な時がありましたが、どれくらいの負荷がどこに
影響するのかわからなかったので、
その場合はすぐにスペック変更できるようにさくらのクラウドにしました。

ディザスタリカバリ、開発用サーバーでまずディザスタリカバリ用に
先程の本番のダンプファイルを保存するサーバーを用意しておく必要があります。

まずディザスタリカバリとは？
ですが、地震、戦争などでデータセンターそのものが破壊された時の事を考えて
地理的に違うサーバーでバックアップファイルを用意しておく事です。

なので、もしさくらのメインのデータセンターの北海道に何かあった場合は
大阪、東京とかのサーバーを使うべきですが、全員が全員同じさくらのサーバーに
引っ越してきたらさすがに大阪、東京のさくらのデータセンターもパンクしてしまう
のではと思うので、念の為違うベンダーにしています。

DR用のディスク容量は最低でも２００GBのキャパシティのサーバーにすべきかと思います。

そこに保存するだけではなく、実際にDBを立ててリストアします。
リストアしたデータで機密情報のあるデータを適当なダミーデータに変更します。
変更後ダンプします。
そのダンプを開発用のサーバーに送ります。

そうすることによって、開発用サーバーでいつでもほぼ本番と同じデータが手元に
あるので、開発→テストがしやすい状況が作れます。

これらの構築ができる状態というのは開発初期ではなく運用のフェーズに入った段階
での作業でそこまで緊急に優先度が高いわけではないと思います。

本番のデータがあるディザスタリカバリ用のサーバーはあくまで管理者のみが
使えるようにして、開発用サーバーとはアカウントもろもろ完全に別に切り離して
おくべきです。

これらが、Linuxのネットワーク構成も含めたベストプラクティスでした。

間違っている、改善点などがあればコメントで指摘してもらえればと思います。