Linuxとネットワークのベストプラクティス
DBのベストプラクティスの動画でも説明したようにLinuxでも基本的にはLinux特有の機能はできる限り抑えて、できる限り誰もが知っているPHPやPythonのサーバーサイドプログラミングで機能開発すべきです。
#10 Linux(CentOS)とネットワークのベストプラクティス【主張】 - YouTube
なので、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のネットワーク構成も含めたベストプラクティスでした。
間違っている、改善点などがあればコメントで指摘してもらえればと思います。
追記
雇ったエンジニアに悪意があっても、セキュリティを担保するにはと考えてみた
で若干上記と考え方は違っています
2022/09/21
登録日：
更新日：