ダンプカンファレンス | grep 'バックエンド|devops'

先週、私はエカテリンブルクで開催された DUMP IT カンファレンス (https://dump-ekb.ru/) に行ってきました。バックエンドと Devops のセクションで何が議論されたか、そして地域の IT カンファレンスが注目に値するかどうかについてお話したいと思います。

Evil Martians の Nikolay Sverchkov がサーバーレスについて語る

いったい何があったのでしょうか？

カンファレンスには合計 8 つのセクションがありました: バックエンド、フロントエンド、モバイル、テストと QA、Devops、デザイン、サイエンス、管理。

ちなみに、最大のホールは Science and Management にあります)) それぞれ最大 350 名まで収容可能です。 バックエンドとフロントエンドはそれほど小さくありません。 Devops ルームは最も小さいですが、アクティブでした。

私は Devops セクションとバックエンドセクションのレポートを聞き、講演者と少し話しました。 カンファレンスでは、取り上げられたトピックについて話し、これらのセクションを復習したいと思います。

SKB-Kontur、DataArt、Evil Martians、エカテリンブルク Web スタジオ Flag、Miro (RealTimeBoard) の代表者が Devops セクションとバックエンド セクションで講演しました。 CI/CD、キュー サービスの操作、ロギングに関するトピックが取り上げられ、サーバーレスのトピックと Go での PostgreSQL の操作が詳しく取り上げられました。

Avito、Tinkoff、Yandex、Jetstyle、Megafon、Ak Bars Bank によるレポートもありましたが、私には実際に出席する時間がありませんでした (レポートのビデオ録画とスライドはまだ利用できません。2 週間以内に投稿すると約束されています) dump-ekb.ru で）。

Devops セクション

驚いたのは、この部が50席ほどの最も小さなホールで開催されたことだ。 通路に立つ人さえいました :) 私がなんとか聞くことができたレポートについてお話します。

ペタバイトの重量を量る弾性体

このセクションは、Kontur の Elasticsearch に関する Vladimir Lil (SKB-Kontur) によるレポートで始まりました。 かなり大規模で負荷の高い Elastic (データ量は約 800 TB、冗長性を考慮すると約 1.3 ペタバイト) があります。 すべての Kontur サービスの Elasticsearch は単一であり、2 つのクラスター (サーバー 7 台と 9 台) で構成されており、非常に重要であるため、Kontur には特別な Elasticsearch エンジニア (実際には Vladimir 自身) がいます。

ウラジミール氏はまた、Elasticsearch の利点とそれがもたらす問題についての考えを共有しました。

メリット：

• すべてのログは XNUMX か所にあり、簡単にアクセスできます
• XNUMX年間のログを保存し、簡単に分析できる
• ログ処理の高速化
• すぐに使える優れたデータ視覚化

問題点

• メッセージ ブローカーは必須です (Kontur の場合、その役割は Kafka によって行われます)
• Elasticsearch Curator での作業の特徴 (Curator の通常のタスクから定期的に高負荷が発生します)
• 組み込みの認証はありません (別途、かなり高額な資金が必要な場合、または運用の準備がさまざまな程度のオープンソース プラグインとしてのみ)

Open Distro for Elasticsearch については肯定的なレビューしかありませんでした :) そこでは、認可に関する同じ問題が解決されました。

ペタバイトはどこから来たのでしょうか?同社のノードは、12*8 Tb SATA + 2*2 Tb SSD を備えたサーバーで構成されています。 SATA 上のコールド ストレージ、ホット キャッシュ (ホット ストレージ) 専用の SSD。
7+9 サーバー、(7 + 9) * 12 * 8 = 1536 Tb。
スペースの一部は、冗長性などのために確保されています。
Kontur、Elba などのすべてのレポート サービスを含む、約 90 のアプリケーションからのログが Elasticsearch に送信されます。

サーバーレス開発の特徴

次は、DataArt の Ruslan Serkin によるサーバーレスに関するレポートです。

Ruslan 氏は、サーバーレス アプローチによる開発とは一般的にどのようなものなのか、またその特徴は何なのかについて話しました。

サーバーレスは、開発者がインフラストラクチャに一切触れない開発アプローチです。 例 - AWS Lambda サーバーレス、Kubeless.io (Kubernetes 内のサーバーレス)、Google Cloud Functions。

理想的なサーバーレス アプリケーションは、特別な API ゲートウェイを介してサーバーレス プロバイダーにリクエストを送信する単純な機能です。 理想的なマイクロサービスであると同時に、AWS Lambda は多数の最新のプログラミング言語もサポートしています。 クラウドプロバイダーの場合、インフラストラクチャの維持と展開のコストはゼロになり、小規模なアプリケーションのサポートも非常に安価になります (AWS Lambda - 0.2 万の単純なリクエストあたり 1 ドル)。

このようなシステムのスケーラビリティはほぼ理想的です。これはクラウド プロバイダーが自ら処理し、Kubeless は Kubernetes クラスター内で自動的にスケーリングします。

欠点があります:

• 大規模なアプリケーションの開発はますます困難になっている
• アプリケーションのプロファイリングが難しい (ログにアクセスできるだけで、通常の意味でのプロファイリングはできない)
• バージョン管理なし

正直に言うと、サーバーレスについては数年前に知りましたが、ここ何年もサーバーレスの正しい使用方法がわかりませんでした。 ルスランの報告の後、理解が現れ、バックエンドセクションのニコライ・スヴェルチコフ（邪悪な火星人）の報告の後、それは統合されました。 カンファレンスに行ったのは無駄ではありませんでした:)

CI は貧しい人々のためのものですか、それとも Web スタジオ用に独自の CI を作成する価値がありますか?

エカテリンブルク出身の Flag Web スタジオの責任者、ミハイル・ラジオノフ氏は、自作の CI/CD について語りました。

彼のスタジオは、「手動 CI/CD」(SSH 経由でサーバーにログインし、git pull を実行し、100 日に XNUMX 回繰り返す) から Jenkins に移行し、コードを監視してリリースを実行できるようにする Pullkins と呼ばれる自作ツールに移行しました。 。

なぜジェンキンスは機能しなかったのでしょうか? デフォルトでは十分な柔軟性が提供されず、カスタマイズが非常に困難でした。

「Flag」はLaravel（PHPフレームワーク）で開発します。 CI/CD サーバーを開発するとき、Mikhail と彼の同僚は Telescope と Envoy と呼ばれる Laravel の組み込みメカニズムを使用しました。 その結果、受信した Webhook リクエストを処理し、フロントエンドとバックエンドを構築し、異なるサーバーにデプロイし、Slack にレポートできる PHP サーバーが作成されます (注)。

その後、Blue/Green デプロイを実行し、dev-stage-prod 環境で統一した設定を行えるようにするために、Docker に切り替えました。 利点は変わりませんが、環境の均一化とシームレスなデプロイメントの可能性が追加され、Docker を正しく操作するために Docker を学習する必要性が追加されました。

プロジェクトはGithubにあります

サーバー リリースのロールバック数を 99% 削減した方法

Devops セクションの最後のレポートは、Miro.com (旧 RealTimeBoard) のリード Devops エンジニアである Viktor Eremchenko によるものです。

Miro チームの主力製品である RealTimeBoard は、モノリシック Java アプリケーションに基づいています。 ダウンタイムなしでデータを収集、テスト、展開することは困難な作業です。 この場合、ロールバックする必要がないように、そのようなバージョンのコードをデプロイすることが重要です (重いモノリスです)。

これを可能にするシステムを構築する途中で、Miro は、アーキテクチャ、使用するツール (Atlassian Bamboo、Ansible など)、チームの構造に関する作業 (現在は専任の Devops チーム + さまざまなプロファイルの開発者からなる多くの個別のスクラム チーム)。

その道は困難で険しいものであることが判明しましたが、ビクターは蓄積された痛みと、それだけでは終わらない楽観主義を共有しました。

質問をする本が当たりました

バックエンドセクション

私はなんとか 2 つのレポートに出席することができました。ニコライ・スヴェルチコフ (Evil Martians) によるサーバーレスに関するものと、グリゴリー・コシェレフ (Kontur 社) によるテレメトリに関するレポートです。

ただの人間のためのサーバーレス

Ruslan Sirkin がサーバーレスとは​​何かについて話した場合、Nikolay はサーバーレスを使用した単純なアプリケーションを示し、AWS Lambda のアプリケーションのコストと速度に影響を与える詳細について話しました。

興味深い詳細: 最小有料要素は 128 MB のメモリと 100 ミリ秒の CPU で、費用は 0,000000208 ドルです。 さらに、そのようなリクエストは毎月 1 万件まで無料です。

Nikolai の関数の一部は 100 ミリ秒の制限を超えることがよくあったため (メイン アプリケーションは Ruby で書かれていました)、Go で書き直すことで大幅な節約が実現しました。

Vostok Hercules — テレメトリを再び素晴らしいものにしましょう!

Grigory Koshelev (Kontur company) によるバックエンド セクションのテレメトリに関する最新レポート。 テレメトリとは、ログ、メトリクス、アプリケーション トレースを意味します。

この目的のために、Contour は Github に投稿された自作のツールを使用します。 レポートのツール - Hercules、 github.com/vostok/hercules、テレメトリ データを配信するために使用されます。

Devops セクションの Vladimir Lila のレポートでは、Elasticsearch でのログの保存と処理について説明されていますが、何千ものデバイスやアプリケーションからログを配信するというタスクは依然として存在しており、Vostok Hercules のようなツールがそれらを解決します。

この回路は、RabbitMQ から Apache Kafka まで、多くの人に知られているパスをたどりましたが、すべてがそれほど単純であるわけではありません)) Zookeeper、Cassandra、Graphite を回路に追加する必要がありました。 このレポート (私のプロフィールではありません) に関する情報は完全には公開しませんが、ご興味があれば、カンファレンスの Web サイトでスライドやビデオが公開されるのをお待ちください。

他のカンファレンスと比べてどうですか？

モスクワやサンクトペテルブルクでのカンファレンスと比較することはできませんが、ウラルでの他のイベントやサマラでの404フェストと比較することはできます。

DAMP は 8 つのセクションで開催され、これはウラル会議の記録です。 科学と管理のセクションが非常に大きく、これも珍しいです。 エカテリンブルクの聴衆は非常に構造化されており、この都市には Yandex、Kontur、Tinkoff などの大規模な開発部門があり、これがレポートにその痕跡を残しています。

もう 3 つの興味深い点は、多くの企業が一度に 4 ～ XNUMX 人の講演者をカンファレンスに招いていることです (これは Kontur、Evil Martians、Tinkoff の場合でした)。 それらの多くはスポンサーでしたが、レポートは他のものとまったく同等であり、これらは広告レポートではありません。

行くべきか、行かないべきか？ あなたがウラル山脈またはその近くに住んでいるなら、あなたには機会があり、そのトピックに興味があります - はい、もちろんです。 長期旅行を考えている場合は、過去のレポートやビデオレポートのトピックスを参照してください。 www.youtube.com/user/videoitpeople/videos そして決断を下した。
地方でのカンファレンスのもう XNUMX つの利点は、原則として、報告後の発表者とのコミュニケーションが容易であることです (単純に、そのようなコミュニケーションへの参加希望者が少ないだけです)。

ダンプとエカテリンブルクに感謝します！ ）

出所： habr.com