ビッグデータは退屈ですか?

MegaFonが使用するビッグデータの分野における開発方法論についての話を続けます(記事の最初の部分はこちら )。 毎日が新しいソリューションを必要とする新しい課題をもたらします。 したがって、開発を組織化する方法は常に改善されています。



今の仕事



継続的デリバリー



かんばんの実用的な実施形態は、非常に迅速なフィードバックを伴う結果です。 継続的デリバリー(CD)の概念は、コンベヤーとして視覚化できるこれらの要件を満たしています。







当社の開発方法論は、非常に短い反復期間を意味します。 このため、CDコンベヤは可能な限り自動化されています。テストの3つの段階はすべて、継続的な統合サーバーで人の介入なしに実行されます。 彼は、「開発」段階で行われたすべての変更を取得し、それらを適用し、テストを実施してから、テストの成功に関するレポートを提供します。 最後の段階である「実装」は、開発者のテスト環境でも自動的に行われ、ユーザー環境での展開には人間のチームが必要です。



単一のアプリケーション(たとえば、単純なWebサイトの作成)について話す場合、CDプロセスは問題になりません。 しかし、プラットフォーム開発の場合、状況は変わります。プラットフォームにはさまざまな用途があります。 データ処理プラットフォームの作成時にすべての変更をテストすることはさらに困難になります。正確な結果を得るには、数十テラバイトのデータをダウンロードする必要があります。 これにより、継続的な統合サイクルが大幅に延長されるため、より小さなタスクに分割し、少量のデータでテストする必要があります。



供給品



CDプロセスの一部として正確に来るもの



•Hadoop( ETL )で実行される通常のプロセス。

•リアルタイム分析サービス。

•分析結果を利用するためのインターフェイス。



典型的なビジネス要件は、3つの配信パッケージすべてを対象としています。定期的およびオンライン(リアルタイム)プロセスを確立し、結果へのアクセスを提供する-インターフェースを作成する必要があります。 さまざまなインターフェイスは開発プロセスを非常に複雑にします;それらすべてはCDプロセスの一部として必須のテストを必要とします。



ノンストップ統合



製品のテスト容易性は、CD方法論の主要な要件の1つです。 これを行うために、開発者のマシン、継続的インテグレーションサーバー、および受け入れテスト環境で配信アイテムを自動的にテストできるツールキットを作成しました。 たとえば、 Apache Pigプログラミング言語で開発されたプロセスの場合、Apache Pigで書かれたスクリプトを大規模なクラスターで実行されているかのようにローカルでテストできるmavenプラグインを開発しました。 これにより、時間を大幅に節約できます。



また、独自のインストーラーも開発しました。 これは、 Groovyに基づいたDSL言語の形式で作成されており、配信の各アイテムの送信先を非常に簡単かつ明確に示すことができます。 利用可能な環境に関するすべての情報(テスト、運用前、および運用)は、作成した構成サービスに保存されます。 このサービスは、インストーラーと環境の間のエグゼクティブインターメディエイトです。



納入品の展開後、自動受け入れテストが実行されます。 このプロセス中に、ユーザーの考えられるすべてのアクションが模倣されます。マウスカーソルを使用した移動、インターフェイスおよびWebページ上のリンクの追跡。 つまり、システムの正しい動作がユーザーの観点から確認されます。 実際、ビジネス要件は受け入れテストの形式で一意に記録されます。 成果物は、自動ストレステストも受けます。 その目的は、パフォーマンス要件への準拠を確認することです。 このために、特別な環境を割り当てました。

次のステップは、スタイルと典型的なコーディングエラーに対するコードの品質の統計分析です。 コードはコンパイラーの観点から正しいものでなければならず、論理エラー、悪名、およびその他のスタイルの欠陥を含んではなりません。 コードの品質はすべての開発者によって管理されていますが、私たちの領域では、そのような分析を配送アイテムに適用することは標準的なステップではありません。



インフラ



テストが成功すると、展開フェーズが始まります。 配送対象物を産業運用に送るプロセスでは、人間の介入なしで制御が自動的に行われます。 サーバーフリートは200台以上のマシンで構成されておりPuppetはサーバー構成の管理に使用されます。 サーバーをラックに物理的に設置し、接続する環境とサーバーの役割を制御システムに示すと、すべてが自動的に行われます:すべての設定のダウンロード、ソフトウェアのインストール、クラスターへの接続、目的の役割に対応するサーバーコンポーネントの起動 このアプローチにより、個別にではなく、多数のサーバーを接続および切断できます。



シンプルな環境設定を使用します



•通常の「鉄」マシン形式の作業サーバー(作業ノード)。

•大容量を必要としないさまざまな実用的なタスクのための仮想マシンのクラウド。 たとえば、メタデータ管理、アーティファクトリポジトリ、監視。



このアプローチにより、実用的なタスクは物理サーバーの容量を占有せず、サービスサービスは障害から確実に保護され、仮想マシンは自動的に再起動します。 ただし、障害が発生するのは運用サーバーだけではなく、簡単に交換したり再構成したりできます。 多くの場合、クラスターを構築する際にクラウドエコシステムに重点が置かれているプラ​​ットフォームについて聞くことができます。 ただし、クラウドを使用して大量のデータを含む「重い」分析タスクを解決することは、費用対効果が低くなります。 従来の非仮想マシンはローカルディスクからの入出力操作でより効率的であるため、使用している環境構築スキームはインフラストラクチャコストを節約します。



各環境は、仮想マシンのクラウドの一部と多数の運用サーバーで構成されています。 特に、オンデマンドで仮想マシン上にテスト環境を用意し、いくつかの問題を解決するために一時的に展開しています。 これらのマシンは、開発者のローカルマシンで作成することもできます。 仮想マシンを自動的に展開するには、 Vagrantアプリケーションを使用します。



開発者のテスト環境に加えて、3つの重要な環境をサポートしています



•受け入れテスト環境はUATです。

•ストレステストの環境-パフォーマンス。

•産業環境-生産。



本番サーバーをある環境から別の環境に切り替えるには数時間かかります。 これは、最小限の人間の介入を必要とする単純なプロセスです。



監視には、分散Gangliaシステムが使用され、ログはElasticに集約され、アラートにはNagiosが使用されます。 すべての情報は、Raspberry Piマイコンを実行している大型テレビで構成されるビデオウォールに表示されます。 それらはそれぞれ、全体的な大きな画像の個別の断片を担当します。 効果的で手頃な価格のソリューション:パネルには、メディアの状態と継続的な配信プロセスの概要が視覚的に表示されます。 開発プロセスがどのように進むか、サービスが産業運用でどのように感じるかについての正確な情報を得るには一目で十分です。



指標



当社が処理するデータの量は、1秒あたり500,000メッセージを超えています。 50,000人のうち、システムは1秒未満で応答します。 分析用に蓄積されたデータベースは約5ペタバイトかかりますが、将来的には10ペタバイトに増加します。



各サーバーは、1分あたり平均50メトリックを監視に送信します。 許容パラメーターをモニターし、アラートを出すインジケーターの数は1600を超えています。



分析結果を使用する



ビッグデータは貴重な情報源です。数字を知識に変え、加入者向けの新製品を開発し、既存の製品を改善し、状況の変化やユーザーの行動パターンなどに迅速に対応できます。



ビッグデータの適用可能性のかなり大きなリストからのほんのいくつかの例を以下に示します。



•ネットワーク負荷分散の地理空間分析:ネットワーク負荷が増加する場所、方法、理由。

•セルラーネットワーク上のデバイスの動作分析。

•新しいデバイスの出現のダイナミクス。



特に、私たちはビッグデータ分析の結果を、無線計画と私たち自身のネットワークインフラストラクチャの近代化に使用します。 また、さまざまな分析をリアルタイムで提供する多数のサービスを作成しました。



オープン市場向けに、私たちは(ロシアの電気通信市場で初めて!)2013年11月に、歩行者や公共交通機関を含む都市の流れを分析するための地理空間サービスを開始しました。 このような非GPSの商用サービスの例は世界にはほとんどありません。



チーム



チームについて少し説明します。 サービスの開発に直接関与するR&Dチームに加えて、すべてのソリューションのパフォーマンスを担当するDevOpsもあります。



彼らは、顧客とともに、タスクの設定プロセスに参加し、各サービスの改善を提供します。 また、開発の品質と機能に要件を課し、テストと受け入れに参加します。 ここでこのエリアについてもう少し読むことができます







モスクワオフィスについては、さまざまな出版物(たとえば、 こちら )で何度も書かれていますが、開発者、DevOps、アナリストは互いに離れた場所で作業していることに注意してください):モスクワ、ニジニノヴゴロド、エカテリンブルグ。 プロセスが損なわれないことを保証するために、私たちは誰にとっても生活を楽にする多くの有料および無料のツールを使用します。



Slackは、開発チーム内と請負業者の両方とのコミュニケーションに非常に役立ちます。 現在、これは一般的に流行の流行傾向ですが、コミュニケーションのツールとしては、非常に優れています。 さらに、内部GitLabに切り替え、すべてのプロセスをJiraとConfluenceに統合しました。 すべてのオフィスに対して、統一された開発標準、統一されたタスク設定ルール、従業員に作業に必要な機器などを提供する統一されたアプローチが導入されています。



時間の経過とともに、私たちはますます多くのタスクに直面します。 したがって、私たちのチームには、さまざまな分野で利益を得ることができる新しい専門家が補充されます。 大規模な電気通信事業者でビッグデータを扱うことは、興味深い野心的な作業です。 そして、私たちは未来について楽観的です-私たちの前には多くの興味深いことがあります。



PS ONE RAILS



ロシア鉄道の子会社は、MegaFonが開発した旅客輸送分析サービスのテストバージョンを受け取りました。 これは、輸送市場の規模と詳細な特性を判断するのに役立つツールです。 このプロジェクトは2016年に商業的に開始される予定です。



MegaFonが提供するサービスにより、ロシア鉄道は旅客交通を管理することができます:人々をある方向または別の方向でチケットを購入するように動機付け、売り上げの減少または増加、および車の占有率を分析します。 受け取った情報を分析することで、すばやく調整できます:チケットの価格を変更する(たとえば、特定の時間帯と「低」シーズンの両方で魅力的にする)、列車のスケジュールを最適化する(ピーク時に追加の列車を追加し、逆に未使用のものを削除する)特定の時間帯の列車の需要)。



たとえば、MegaFonのサービスは、今年の5月の休暇中にモスクワ-ヴォルゴグラード-モスクワルートを分析しました。需要は昨年の同時期と比較して6.8%増加しました。 同時に、このサービスは、過去1年間のモスクワ-ボルゴグラードルートでの常連客の損失が8.3%であることを示しました。



MegaFonは、ロシアの運送会社がこのような研究に12億ルーブル以上を費やしていると推定しています。 毎年。 同時に、企業自体は利用可能なデータの一部のみを収集でき、モバイルオペレーターのサービスにより、市場全体の全体像を見ることができます。これにより、航空会社は一般旅客輸送市場でシェアを1.5〜2%増やします。 そして、これは数十億ルーブルです。



All Articles