Антон Пацев

lightsail, как можно догадаться по названию, это упрощенный(легкий) интерфейс над вычислительными - Elastic Compute Cloud (EC2) сервисами. И немного более дешевый в связи с тем, что контроля вам дают мало. Однако он сразу реализует некоторые паттерны и наборы сервисов для быстрого старта. Это - путь стартапов.
Lightsail, насколько я помню, запускается в "VPC по умолчанию" которым управляет AWS и где все сервера живут в публичной подсети, что небезопасно.

Та схема которую вы хотите, наверное, реализуется lightsail-ом, но для большего контроля все таки рекомендуется организовать свой VPC (Virtual Private Cloud) - компонент сетевых сервисов AWS.
В вашем случае потребуется что-то вроде(для оценки стоимости) :

1. Балансировщик :
- ALB\ELB сервис (отдельный прайсинг). HA сервиса обеспечивает AWS
или
- два инстанса нужного вам балансировщика (Nginx, HAProxy и другие). HA и прочая обеспечиваете вы.

2. N бэкендов нужного типа (смотрите стоимость конкретного инстанса соответствующего вашим потребностям)

3. реплицируемые базы :
- вы можете взять 2 инстанса нужной мощности(платите за инстансы) и настроить все сами
или
- взять RDS (отдельный сервис, другой прайсинг) нужной базы где HA и обслуживанием будет заниматься AWS для вас, предоставляя вам эндпойнт для подключения с серверов.

4. Файловое хранилище. Тут интереснее
Если у вас Windows : вам понадобятся два инстанса для обеспечения отказоустойчивости и HA
Если у вас *nix : вы можете сделать так же как с WIndows или взять EFS (отдельный сервис, где вы платите за занятое место) который высокодоступен и может быть подключен к разным *nix инстансам одновременно.

5. Внутренности VPC
VPC организуется так же как и любая сеть в железном эквиваленте.
Подсети - приватные, публичные
Настройка роутинга для публичных подсетей, для приватных подсетей через NAT инстанс\сервис
NAT инстанс или сервис
VPN инстанс или бастион (для доступа к инстансам в приватной подсети)

Вот тут вы уже можете подсчитать во сколько обойдется примерно владение только инстансами и необходимыми сервисами.
Сколько у вас будет непредвиденных расходов на передачу данных и тп. - вы сможете увидеть только по результатам билинга за первый месяц.

Это мое личное мнение по тому, как следовало бы сделать в вашем случае.
Может статься, что вы не осилите (у каждого своя скорость освоения) это достаточно быстро и быстрее реализуете другую схему - это на ваш выбор

А если так

#!/usr/bin/env python3

import os
import json

s = os.popen("ps axho comm --sort -rss | head -5").read()

service_states = s.split()

count = 0
data = {}

for i in service_states:
    count += 1
    key = "{#TOPMEMNAME" + str(count) + "}"
    data.setdefault("data", []).append({key:i})

print(json.dumps(data, sort_keys=True, indent=2))

Вывод:

{
  "data": [
    {
      "{#TOPMEMNAME1}": "python3"
    },
    {
      "{#TOPMEMNAME2}": "bash"
    },
    {
      "{#TOPMEMNAME3}": "ps"
    },
    {
      "{#TOPMEMNAME4}": "head"
    },
    {
      "{#TOPMEMNAME5}": "sh"
    }
  ]
}

Подшаманил чуть-чуть.

Под периодическим обслуживанием я подразумеваю vacuum, reindex, analyze

А зачем?
Обратите внимание: это вопрос от postgresql DBA. Да, у нас есть таблицы и на несколько террабайт.

После нормальной настройки автовакуума под железо (вместо дефолтных настроек под любую кофеварку) с вакуумом и analyze нормально справляется автовакуум.
Вместо reindex - pgcompacttable, pg_repack, да хоть вручную или каким-нибудь своим скриптом create index concurrently + drop index concurrently

Настроек у него никаких, поэтому достаточно проверить, что он загружен, т.е. упомянут в
show shared_preload_libraries;

А зачем нам другие ЯП если всё можно на C написать ?)

А вообще для Питон разработчика проще освоить Go чем Cи и сравнительно быстро начать оптимизировать питон при помощи Golang -a. Я видел как люди большие проекты переписывают на Go путём вынесения тяжелых кусков в Go и со временем вообще уходят от питона.

sudo curl -L https://raw.githubusercontent.com/pixelb/ps_mem/master/ps_mem.py --output /usr/local/bin/psmem

sudo chmod +x /usr/local/bin/psmem

psmem

вернет подробную таблицу (Shared, private) используемой памяти по каждому запущеному демону

pg_repack - это community extension, форк более раннего pg_reorg. И не отрицая вклад участников pgpro в разработку postgresql в целом - я не вижу их среди контрибьютеров pg_repack.

Мы активно используем обе. Основные моменты касательно pg_repack vs pgcompacttable в общем-то именно я и изложил в README компактора. Если говорить на русском:
- pg_repack делает копию таблицы, т.е. требуется двукратный запас диска. Компактор работает в рамках одной таблицы и требует место только под копию наиболее толстого индекса и то, толстые индексы обрабатываются самыми последними. Т.е. расчёт на работу когда места уже мало.
- компактор намеренно выполняется медленно чтобы не задевать работающий проект
- компактор не может обрабатывать toast таблицы. Репак - может.
- pg_repack характеризуется очень заметными пиками io и wal. Вся таблица едет одной транзакцией и это никак не регулируется. Поэтому может аффектить прод на неважных дисках и в том числе оторвать реплики при недостатке сетевой полосы.
- pg_repack умеет перемещать между tablespace и может делать команду cluster

(или лучше подстроить автовакум)?

Конечно необходимо настроить автовакуум и не мешать ему работать - т.е. исключить долгие транзакции. Но всё равно бывают хитрые моменты, когда репак или компактор бывают нужны.

pssh
ansible
...

GLPI
Установка