ホーム

スタッフブログ

2021年10月29日

開発手記(5-3)サーバー増強・技術面について

こんにちは

システムチーム プログラマー / マネージャー のAです。

前回に続き、サーバー増強の話です。

今回は技術面に寄り添った話になります。

 

ダウンタイム「0」でリリースを行いました

1つ前の記事で

– 何よりも価値があるのは「見積り通り完了した」こと

– 次点で、「ダウンタイムを0で改修しきった」ことだと思います。

と話しましたが、その「ダウンタイム」の話になります。

 

今回、

リリース作業には6時間程度を要したんですが

途中、変化を感じることが出来たユーザーさまはいらっしゃらないと思います。

断言はできないんですが、おそらく。

 

システムを止めないのは当たり前。

システムが変わってる事を気づかせてはいけない。

と思いながらリリース手順を組みました。

リリース手順は全て合わせて「40」。多い。

 

幸いなことに、

デキテルには、ほぼ毎秒アクセスが発生しています。

何かの処理に1秒以上要すれば、何かの整合性は崩れます。

でも、処理を1秒未満に抑えることは、不可能。

 

じゃあどうするか。

一時的に「整合性が崩れる」前提で、気付かれる前に整える。

そのために「整合性の崩し方」を制御する必要がありました。

完全にコントロールした「崩れ」は、もはや「崩れ」ではありません。

 

リテラシー的に詳細は書けないですが、

上記の様な発想で構成したリリース手順で、

ダウンタイム「0」を実現できました。

システムを止めた前例が出来なくて、本当に良かったと思います。

 

 

サービス特有の仕方ない問題

どのサービス・システムでも、必ず、

「そうするしかなかった事情」があります。

 

例えば

レガシーな言語を利用しているとか、

一般的にはあまり見ない書き方をしているとか、

どのサービス・システムでも、何かの事情はあります。

 

基本的に、

プログラマーはその事情を拝察した方が良いと思っています。

自分だって、無意識に、何かの事情を抱えています。

互いに傷つけあうより、分かりあう方が良いです。

 

今回は

・PHP8がパ―スすら出来ないコードが複数ある

・単一サーバーで全てが完結する前提の仕組み

といった事情がありましたが、

全てを受け止め、責任をもって、進化させました。

 

 

インフラに、正解は無い

「大変」ばっかり続いて嫌になってきましたが

デキテルに適切なインフラを用意することは、大変でした。

 

インフラに正解はありません。

開発者が、責任をもって、正解を定義する必要があります。

 

セキュリティ対策は特に分かりやすく、

「これさえしておけばOK」的な正解を用意してしまうと、

その「正解」をベースに、システムハックをスタートできます。

「おすすめのSSHのポート番号は40192です」なんて言えるわけないんです。

 

だから、

国や、専門家が責任を持って発信している情報や

自分で収集したサービス特有の情報を元に、

サービスに最適な構成を自分で定義し、形にする。

そういった仕事だったように思います。

 

 

全て出し切った

今回の改修では

今までに仕入れてきた知識を使い切りました。

 

といっても

過剰な内容ではなく、

サービスが最適な状態で存在するために、知識を使いました。

 

例えばPHP8。

別に、サーバー移転だけであればPHP8じゃなくていい。

PHP5.6系でも、7でも、動きはします。

ただ、

将来PHPのバージョンが古いことで

問題が発生する可能性を考慮し、決行しました。

 

HTTP2対応も、Gzip転送も

必須な内容ではなかったんですが

将来的な問題を考慮して、決行しました。

 

セキュリティ対策も同様に、

サービス特有の事情を尊重する前提で、やるべきことは全て行いました。

 

何かに、責任をもって正解を定義することは難しい。

インフラ構築では、その難しさを再確認しました。

 

ただ、元も子もない話ですが

サーバー増強というタスク自体にも、

「どうなればOK」という正解はありませんでした。

 

最初から薄々とは気づいていたんですが

リリース日が近づくほど、悩んだ問題でした。

次の記事ではその話をします。

次→https://syde.jp/w/archives/11553.html

 

求人バナー

このページの上部へ戻る