在我的架构验证中，最佳实践是什么？

2 年 ago

科, 雅

1 minute

由于过去半年参与了各种验证工作，因此我将其内容进行了抽象总结。

几乎是按照我的方式进行的，所以我个人认为这是最佳实践，但不能否认可能存在更好的方法。
（使用”个人”这个词是为了保险起见。）
说真的，肯定有更好的方法！但这样的信息并不经常流传出来！所以如果有改善的地方，请告诉我m(__)m

术语的定义

“建筑风格”

在本书中，我们使用术语”架构”来指代“用于运行某软件所需的服务器群和中间件的结构”。

“验证”

本文书将讨论“验证”一词，涉及以下两种主要验证方法。

在该体系结构中，确认符合哪种机器规格才能满足非功能需求的性能验证

免责

由于我的公司是在本地环境中建设的，所以如果基于云服务使用的话，可能验证的要求可以放松一些。
我对此并不太清楚，还请见谅…。

在进行验证设计之前…

如果没有明确的验证目的，无论思考多少验证内容都没有意义。所以在以下信息完善之前，我们要努力进行架构审查☆

功能要求 – (Functional requirements)

首先，需要明确的是要开发的软件是为了实现什么，将提供什么样的用户体验。根据用户的需求，系统方面会产生哪些要求。让我们明确地规划好这些要求。

非功能需求

不仅需要确定软件本身的功能，还需要确定是否容许双重故障，容忍的延迟程度等非功能方面的要求。由于观点众多，这很困难，但我们参考了IPA的”非功能需求等级”来进行制定。

如果方便的话，请参考一下”非功能需求等级”，这是实现对非功能需求的可视化和确认手段的公开方式。

建筑设计方案

对于被验证的架构命名为“仮案”的原因是，由于验证结果可能推翻该架构的可能性存在！(实际上发生了…)

我觉得具体来说，如果能够收集到以下的这些信息就好了。

障害時の対応

进行功能验证的方法

那么，我将具体介绍从验证设计到执行的步骤！大致上，我们将按照以下流程进行。

「何が見たいのか」を明確にする
必要な検証環境を考える
確認項目と、その確認方法の洗い出し
具体的な検証手順を書き出す

手を動かすフェーズ

検証環境の構築 / スクリプトの準備(必要であれば)
検証実施！

现在让我们逐一仔细看一看吧！

明确定义想要看什么

让我们重新确认验证的主要目的。首先，我们将尽可能列举“如果无法确认这一点会感到不安”的观点。常见的观点包括以下内容。

機能要求が満たすよう動作してくれるか
障害時、想定しているようにフェイルオーバしてくれるか

性能面での不安

通常時の負荷の時、非機能要求を満たせているか
ピーク時の負荷の時、エラーや極端な遅延が発生しないか

然后，根据项目的情况，整理需要确认的内容，例如“这个是需要确认的”、“即使犯错最糟糕也能在后面解决”。

考虑所需的验证环境。

在考虑验证想要观看的内容时，我们需要考虑所需的验证环境。

▼我们的目标是收集最低限度以下的信息。

OSは?
インストールするミドルウェアは?
マシンスペックは?

CPUモデルとクロック数
CPUのコア数
メモリ
ディスク

HDDかSSDか
サイズ
IOPS

ネットワーク

外部ネットワークか内部ネットワークか
帯域幅

性能検証时需要注意的要点

基本上，我覺得可以通過在雲端創建實例，觀察在負載下的資源消耗，然後根據需要提高或降低機器規格，以找到滿足非功能需求的適當數值。

因此，在一開始時，機器規格只能暫時放置，我認為最好的方法是根據直覺估計「這個規格應該足夠好了」。

相較於從1核心1GB開始逐步提升，這種方式應該更為高效。

3. 列出确认项目以及相应的确认方法.

我们应该考虑具体验证中需要确认什么，如何进行确认，以及如何记录确认结果！

如果要列举常见的确认事项，我能想到以下的一些：

CPU使用率
メモリ使用率
IOPS
Net IO
Load average
ディスクIO

処理関連

レイテンシー
エラーが発生しないか

DB関連

コネクション数
データ件数

另外，我经常使用的确认方法如下所示。

dstat -tcmlrdn で全部見れます

処理関連

スクリプトにレイテンシーを出力したり、負荷テストツールのプラグインを使ったり…

DB関連

コネクション数

MySQL – mysqladmin -h -u root -p -i 60 extended-status|grep conn
Cassandra – nodetool netstats

データ件数

MySQL – SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = ‘your db name’ AND TABLE_NAME = ‘your table name’;
Cassandra – SELECT COUNT() FROM table name もしくは nodetool cfhistograms(estimateの値)

闲聊：对于资源消耗记录，使用ddstat非常方便。

在监控资源消耗的时候，通常我会使用dstat，在仅仅观看数字的情况下，并不能很好地了解整体情况，我经常渴望有图表来帮助我。这种情况下，ddstat非常实用！

我做了一个将dstat实时数据转化为图形的工具ddstat。

Datadog是一个提供数据保留服务的免费账户，但它只能保留24小时的数据，不过对我来说没什么大问题，只要快速保存结果就好。

最近我也在考虑安装像Zabbix、Munin一类的监控工具，也许这也是一个选择，虽然可能有点夸张。

余談2：在进行各种监控时，屏幕非常方便！

当我在进行各种监视时，作为一个初学者的我像个傻瓜一样打开了很多窗口……。
如果使用screen，就不需要做这样的事情了！

基本上，我是这样想的

ctrl+a d でディタッチ

我只使用过一次，但非常方便而且救了我的命。
请参考下面这篇文章以了解更详细的使用方法。
screen命令的要点。

4. 写下具体的的验证步骤。

只要按照这份文件的指示按键操作，就能完成验证，这是制定验证步骤的目标，直到达到” “的水平。
我想象中的画面像下面这张图片：

備考

我正在一步一步地写这个。

诚实地说，我觉得在这里可能还有一些可以做出改进的地方…但是，由于我想不到其他更好的方法，所以目前我只能使用这个格式进行总结。

5. 建立验证环境/准备脚本（如果需要）

让我们构建用于进行验证的环境，并实施脚本！
由于不同的验证会有不同的要求，在本文档中不会详细说明这个部分。
但是，这通常是出现最多问题的地方…。

而且，绝对！！！需要做的一件事是整理环境设置步骤并做好备忘录。当部署到生产环境时，或者团队成员在类似的环境中进行某种实现时，为了未来的自己…这种未来可能会有很高的可能性出现，会对未来有帮助的时刻。这几乎不需要花费太多时间，所以务必务必做好备忘录！而且，如果你还创建了一个Ansible的Playbook，你的同僚们可能会抬头仰望你。

进行验证！

只需要执行并整理结果了。
如果没有问题的话，应该很快就能完成。
嗯，通常会遇到问题…。

结束时

辛苦了。

请问我的验证方法最佳实践，您觉得如何呢？如果对您有帮助的话，我就感到很幸福了。

另外，如果您有任何反馈，请务必告诉我们！祝您度过愉快的验证生活～。