вторник, 22 мая 2018 г.

Еще немного об оптимизации

      С одной стороны я понимаю что все эти знания скорее всего останутся невостребованными и что я никогда не применю их в своей практике, но все равно это интересно. Прочитал недавно статью https://code.facebook.com/posts/206591859504673/three-optimization-tips-for-c-/ помимо отменного юмора она содержит и классики (вроде - измеряй прежде чем оптимизировать!) статья содержит много практических советов:
  • Помнить о стоимости различных операций. Кстати то что деление целых чисел дороже чем операции с float стало для меня открытием
  • Элегантные примеры замены операций деления на операции сравнения
  • Доступ к элементам массива по индексу  быстрее чем по указателю
  • Компилятор умеет автоматически заменять операции деления на операции умножения - https://gmplib.org/~tege/divcnst-pldi94.pdf  

пятница, 18 мая 2018 г.

Amazon Aurora

    Сегодня открыл для себя Amazon Aurora - несгибаемый вариант MySQL от Amazon. Очень интересная штука,  особенно в плане дизайна. Нашел немного информаци  про его внутреннее устройство:
В общем выглядит ка серебряная пуля. Особенно если добавить сюда возможность шифрования на лету
https://aws.amazon.com/blogs/database/encrypting-amazon-aurora-using-aws-kms-and-your-own-cmk/  и поддержку PostgreSQL.  Причем в https://en.wikipedia.org/wiki/Amazon_Aurora написано что сделали Amazon Aurora на базе MySQL.  В общем интересно было бы посмореть на опыт реального использования этого чуда техники. 

понедельник, 14 мая 2018 г.

Kubernetes(K8s) + Docker

      Я долгое время вынашивал идею доклада который бы обобщил накопленный мною и моими коллегами опыт. К сожалению с докладом не срослось в силу разных причин, поэтому напишу хотя бы небольшую заметку. 
       Сейчас про Docker и Kubernetes не пишет разве что ленивый, но в большинстве своем это либо рекламные проспекты,  либо статьи из разряда - как запустить сделать свой нахер никому не нужный блог безмерно масштабируемым. В этой статье не будет никаких сверхъестественных технологий и запатентованных магических технологий. Просто рецепт как МОЖНО эксплуатировать связку докер + кубернейтс в production среде. В действительно высоко нагруженной production среде, обрабатывающей десятки тысяч запросов в секунду, состоящей из нескольких сотен серверов.  Обратите внимание на слово - МОЖНО. То есть я не претендую на истину в последней инстанции. Наверняка что-то можно было сделать и лучше. Но мы сделали так как написано и у нас это не плохо работало.
          1. При эксплуатации докера очень много зависит от совместимости версии самого докера + версии ядра + версии кубера. Поэтому кратенько приведу то что мы использовали: Docker 1.13.1,  Linux version 3.10.0-327.el7.x86_64, CentOS Linux release 7.2.1511, Kubernetes v1.5.5. Время идет и даже на момент публикации поста эта информация уже порядком устарела, но я все же оставлю ее здесь.  Скорее всего вы будете использовать другие версии, но нужно подходить к этому очень осторожно. Docker печально известен своей нестабильностью, поэтому прежде чем деплоить новую комбинацию версий в продакшен - ей нужно дать "отстоятся" на паре-тройке серверов в течении 2-3х недель.  
    2. Сеть.  Мы использовали стандартную сеть на основе linux bridge + BGP для маршрутизации трафика между серверами. То есть на каждый сервер выделялась /24 подсеть(к примеру 10.216.0.1/24), первый адрес подсети выделялся самому серверу(10.216.0.1) а остальные выделялись kubernetes подам запущенных на этой машине. Для всех подов 10.216.0.1  прописывался как default gateway. 
Также на каждом хосте стояла quagga которая анонсировала 10.216.0.1/24 сеть по BGP протоколу. 
        3. Сторадж: STORAGE_DRIVER=overlay,  файловая система xfs. Когда мы начинали свой поход в продакшен мы перепробовали много вариантов, но сейчас это уже стало стандартом de-facto. 
       4. Мониторинг - Prometheus + Grafana + telegraf для сбора метрик с хостов. Прометей стоял отдельно, без всяких новомодных Prometheus Operator.  
      5. Логгирование тоже было сделано крайне просто - на каждом хосте стоял rsyslog, который слушал unix domain сокет. Директория с этим сокетом пробрасывалась в каждый контейнер. Обращаю внимание что пробрасывался не сам сокет а только директория в которой он находился. Так сделано потому что контейнеры должны иметь возможность переоткрыть его если к примеру rsyslog перезапускали.  Весь софт только и знал что писал в этот сокет. rsyslog вычитывал это, аггрегировал, при необходимости буфферизировал на диск и отправлял по сети на центральный лог сервер.
       6. Load balancing + DNS - мы не использовали возможности предоставляемые кубером для балансировки нагрузки. У нас все было через ServiceDiscovery, поэтому компоненты сами друг сдругом общались. Peer to peer. Не буду говорить о том хорошо это или плохо. Вообще про балансировку можно отдельно рассказать. 

вторник, 8 мая 2018 г.

Get right things done

      Дочитал наконец-то до конца книгу Питера Друкера(Peter Drucker) - The effective executive.  Что я вам скажу - это одна из тех книг которые полностью переворачивают твое понимание вещей. После ее прочтения на многие вещи начинаешь смотреть по другому. Я очень жалею что не открыл ее для себя раньше. Это помогло бы мне избежать стольких ошибок!!
Когда я ее читал я испытывал смешанные чувства. Иногда я находил подтверждение правильности некоторых решений/принципов к которым я приходил интуитивно. Иногда я хватался за голову и думал - ах вот почему тогда-то у нас ничего не получилось. Причем вторая ситуация случалась сильно чаще чем первая.
     В общем я категорически рекомендую эту книгу всем кто так или иначе называет себя менеджером либо хочет им стать. На очереди The Practice of Management написанная им же. 
Do first things first and second not at all!!