私はThe Economistのエンジニアリングチームに、Drupal Developerという職で加わった。しかし、実際のタスクは、Economistのコンテンツ配信技術を根本的に作り直すプロジェクトへの取り組みだった。最初の数ヶ月はGoの習得に費やし、MVPを構築するために外部コンサルタントと数ヶ月間協業し、そのあと、Goへの旅路を案内するため再びチームに参加した。
ニュースの消費が印刷物から離れていくにつれ、The Economistの使命を果たすべく、より多くのデジタルオーディエンスにリーチするための技術変革が行われてきた。ますます増える多種多様なデジタルチャンネルにコンテンツを届けるため、The Economistにはさらなる柔軟性が必要だった。この柔軟性という目標を達成し、ハイレベルなパフォーマンスと信頼性を維持するため、プラットフォームをモノリスからマイクロサービスアーキテクチャへ移行した。Goで書かれたサービスがニュースシステムの重要コンポーネントになっており、The Economistはこれによって、スケーラブルでハイパフォーマンスなサービスを提供し、新プロダクトをすばやくイテレーションできるようになった。
The EconomistにおけるGoの実践
- エンジニアはすばやくイテレートしながら新機能を開発できるようになった
- スマートなエラー処理で、「すばやく失敗する」というサービスのベストプラクティスを実践した
- 分散システムにおける並行性とネットワーキングのための堅牢なサポートを提供した
- コンテンツおよびメディアに要求される一部領域において、成熟度とサポートがやや足らなかった
- デジタル出版を大規模に実行できるプラットフォームの実現を容易にした
なぜThe EconomistはGoを選んだのか？
この質問に答えるには、新しいプラットフォームの全体的なアーキテクチャを説明しておくとよいだろう。このプラットフォームはContent Platformと呼ばれ、イベントベースのシステムになっている。各種コンテンツオーサリングプラットフォームからやってくるイベントに応答し、個別のワーカーマイクロサービスで実行される一連のプロセスをトリガーする。これらサービスは、データの標準化、セマンティックタグ解析、ElasticSearchにおけるインデックス作成、Apple NewsやFacebookなど外部プラットフォームへのコンテンツプッシュといった機能を実行する。また、プラットフォームはGraphQLと組み合わされたRESTful APIを備えており、これがフロントエンドクライアントおよびプロダクトの主な入り口になっている。
チームは全体的なアーキテクチャを設計しながら、どの言語がプラットフォームのニーズに合っているか検討した。Goとともに、Python、Ruby、Node、PHP、Javaが比較された。どの言語にも長所はあるが、プラットフォームのアーキテクチャにはGoが最適だった。Goに組み込まれた並行処理とAPIサポート、および静的コンパイル型言語としての設計のおかげで、大規模にスケール可能な分散イベントシステムを実現できる。さらに、Goの比較的シンプルな構文は、習得して動作するコードを書きはじめやすく、非常に多くの技術移行を経験してきたチームにとってたやすいことだった。全体として、分散型クラウドベースシステムの有用性と効率性にとって、Goが最適な言語だと判断された。
それから3年、Goは野心的な目標を達成したか？
プラットフォーム設計のいくつかの要素は、Go言語とうまくマッチしていた。分散し独立したサービスから構成されているため、システムにとって「すばやく失敗すること」は重要な部分だった。Twelve Factor App原則に従い、アプリケーションはすばやく起動して失敗する必要があった。静的コンパイル型言語としてのGoの設計は、すばやい起動時間を可能にした。コンパイラの性能は継続的に改善され、エンジニアリングおよびデプロイメントにおいて問題になることはなかった。加えて、Goのエラー処理設計により、アプリケーションはすばやく失敗できるだけでなく、よりスマートに失敗することができた。
エラー処理
エンジニアがすぐに気づいたGoの相違点は、例外がなく、Error型があることだ。Goでは、すべてのエラーは値である。Error型は事前に宣言されたインタフェースだ。Goのインタフェースは基本的に名前の付いたメソッドの集合であり、同じメソッドを持っていれば、どんなカスタム型でもそのインタフェースを満たすことができる。Error型は自身を文字列で記述できるインタフェースだ。
type error interface {
Error() string
}
エンジニアはこれによりエラー処理に関する制御と機能を実現できる。任意のカスタムモジュールに文字列を返すErrorメソッドを追加することで、カスタムエラーを作って、ErrorsパッケージにあるNew関数のようにエラーを生成できる。
type errorString struct {
s string
}
func (e *errorString) Error() string {
return e.s
}
これは実際に何を意味しているのか？ Goの関数は複数の値を返すことができ、失敗する可能性がある関数がは、エラー値を返す可能性が高い。Go 言語では、エラーが発生した場所でエラーを明示的にチェックすることが推奨される（例外をスローしてキャッチするのではなく）。そのため、"if err != nil" といったチェックが通常行われる。こうしたエラー処理を頻繁に行うのは、最初のうちは繰り返しのように思うかもしれない。しかし、値としてのErrorのおかげで、エラー処理を簡単化することができる。例えば、分散システムの場合、エラーをラップすることで簡単に再試行できる。
他の内部サービスへの送信であれ、サードパーティ製ツールへのプッシュであれ、ネットワーク問題は必ず発生するものだ。Netパッケージにある次の例は、エラーを一時的なネットワークエラーと恒久的なエラーを区別するタイプとして利用している。The Economistチームでは、コンテンツを外部APIにプッシュする際のインクリメンタルな再試行を組み込むために、同様のエラーラッピングを用いている。
package net
type Error interface {
error
Timeout() bool // Is the error a timeout?
Temporary() bool // Is the error temporary?
}
if nerr, ok := err.(net.Error); ok && nerr.Temporary() {
time.Sleep(1e9)
continue
}
if err != nil {
log.Fatal(err)
}
Goの作者は、必ずしもすべての例外が例外的なものではない、と考えている。エンジニアは、アプリケーションを失敗させるのではなく、うまくエラーから復旧させることが推奨される。また、Goのエラー処理は、エラーをさらに制御できるようにし、デバッグやエラーの有用性を向上させることができる。Content Platformでは、このGoの設計のおかげで、開発者がエラーについて慎重に判断を下せるようになり、その結果、システム全体の信頼性が向上した。
一貫性
Content Platformにおいて、一貫性は重要な要素だ。コンテンツはThe Economistのビジネスの中心であり、Content Platformの目標は、コンテンツを一度公開したらどこでも読めるようにすることだ。そのため、すべてのプロダクトとコンシューマは、Content Platform APIから一貫性を保っていることが不可欠だ。プロダクトは主に、GraphQLを使ってAPIをクエリする。これには、コンシューマとPlatformとの間の契約として機能する静的スキーマが必要となる。Platformが処理するコンテンツは、このスキーマと一貫性がある必要がある。静的言語はこれを強制するのに役立ち、データの一貫性を確実にするのを容易にした。
Goでのテスト
一貫性を向上させるもう1つの機能は、Goのテストパッケージだ。Goの高速なコンパイル時間と、ファーストクラス機能としてのテストを合わせることで、チームはエンジニアリングワークフローに強固なテストプラクティスを埋め込み、ビルドパイプラインにおけるすばやい失敗を実現した。"go test" を実行すると、カレントディレクトリにある全テストが実行される。testコマンドには便利な機能フラグがある。"cover"フラグはコードカバレッジに関する詳細なレポートを提供する。"bench"フラグはベンチマークテストを実行する。ベンチマークテストは、テスト関数を “Test” ではなく “Bench” で始めることで指定する。TestMain関数は、モック認証サーバーなど追加のテスト設定のためのメソッドを提供する。
さらにGoでは、匿名構造体を使ったテーブルテストやインタフェースを使ったモックを作って、テストカバレッジを改善できる。言語機能に関して、テストは新しいものではないが、Goは堅牢なテストが書きやすく、テストをシームレスにワークフローに埋め込みやすい。The Economistのエンジニアは、最初から特別なカスタマイズなしに、ビルドパイプラインの一部としてテストを実行することができた。また、Git Hooksを追加することで、Githubにコードをプッシュする前にテストを実行することができた。
とはいえ、プロジェクトは一貫性を実現するのに苦労しなかったわけではない。プラットフォームの最初の大きな課題は、予測不能なバックエンドからやってくる動的コンテンツを管理することだった。プラットフォームは主として、データ構造と型が保証されていないJSONエンドポイント経由で、ソースCMSシステムからのコンテンツを消費する。このことは、プラットフォームがGoの標準encoding/jsonパッケージを使えないことを意味する。このパッケージは、JSONを構造体にアンマーシャリングすることをサポートし、構造体フィールドと受信したデータフィードの型が一致しない場合、パニックになる。
この課題を克服するには、バックエンドを標準フォーマットに対応づけるカスタムメソッドが必要だった。このアプローチを数イテレーションやった後、チームはカスタムのアンマーシャリングプロセスを実装した。これは標準のlibパッケージを再構築するように少し感じたが、エンジニアはソースデータの処理方法をより細かく制御できるようになった。
ネットワーキングのサポート
スケーラビリティは新しいプラットフォームにおける重点であり、ネットワーキングとAPIに関するGoの標準ライブラリがこれをサポートした。Goでは、フレームワークを必要とせずに、スケーラブルなHTTPエンドポイントをすばやく実装できる。以下の例では、標準ライブラリnet/http パッケージを用いて、リクエストおよびレスポンスライターを引数とするハンドラをセットアップしている。Content Platform APIを最初に実装したときはAPIフレームワークを使っていたが、最終的には標準ライブラリに置き換えた。追加の手間をかけなくても、標準ライブラリは自分たちが必要としているネットワーキング機能をすべて満たしているとわかったためだ。ハンドラにおける各リクエストは、カスタマイズすることなく、軽量スレッドであるGoroutineで同時実行されるため、GolangのHTTPハンドラはスケールする。
package main
import (
"fmt"
"log"
"net/http"
)
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello World!")
}
func main() {
http.HandleFunc("/", handler)
log.Fatal(http.ListenAndServe(":8080", nil))
}
並行処理モデル
Goの並行処理モデルは、プラットフォーム全体でいくつかのパフォーマンス向上をもたらした。分散データを扱うということは、コンシューマに約束した保証と格闘することを意味する。CAP定理によると、一貫性（Consistency）、可用性（Availability）、分断耐性（Partition tolerance）という3つの保証のうち、2つ以上を同時に実現することは不可能だ。The Economistのプラットフォームで受け入れられたのは、結果整合性（Eventual Consistency）だった。つまり、データソースからの読み出しは、結果的に整合性がとれていればよく、すべてのデータソースが一貫性のある状態になるまでの適度な遅延は許容される。このギャップを最小限に抑える方法の1つは、Goroutineを利用することだ。
GoroutineはGoランタイムが管理する軽量スレッドで、スレッドの枯渇を避けることができる。Goroutineを使うことにより、プラットフォーム全体の非同期タスクの最適化が可能になった。例えば、Platformのデータソースの1つにElasticsearchがある。システムでコンテンツが更新されると、コンテンツを参照しているElasticsearchでそのアイテムを参照しているコンテンツが更新され、インデックスが再作成される。Goroutineを実装することで、再処理の時間が短縮され、アイテムはすばやく一貫性を保てるようになる。次の例は、再処理すべきアイテムがGoroutineでそれぞれ再処理されるのを示している。
func reprocess(searchResult *http.Response) (int, error) {
responses := make([]response, len(searchResult.Hits))
var wg sync.WaitGroup
wg.Add(len(responses))
for i, hit := range searchResult.Hits {
wg.Add(1)
go func(i int, item elastic.SearchHit) {
defer wg.Done()
code, err := reprocessItem(item)
responses[i].code = code
responses[i].err = err
}(i, *hit)
}
wg.Wait
return http.StatusOK, nil
}
システムの設計は単なるプログラミング以上のものであり、エンジニアはいつどこでどんなツールが機能するのか理解する必要がある。GoはThe EconomistのContent Platformのニーズのほとんどにとって強力なツールだったが、いくつかの制限のために他のソリューションも必要になった。
依存関係管理
Goがリリースされたとき、依存関係を管理するシステムはなかった。そこで、このニーズを満たすために、コミュニティでいくつかのツールが開発された。The EconomistはGit Submodulesを用いた。コミュニティが標準の依存関係管理ツールを積極的に進めている時点で、これは理にかなっていた。現時点で、コミュニティは依存関係管理のための協調の取れたアプローチへ近づいているが、まだ登場していない。The Economistでは、submodulesによるアプローチが大きな課題になることはなかったが、これが課題になっているGo開発者もおり、Go移行時に検討すべきものになっている。
Platformにとって、Goの機能や設計が最適ではない要件もあった。Platformがオーディオ処理のサポートを追加したとき、メタデータ抽出のためのGoツールは限られていたため、代わりにチームはPythonのExiftoolを選んだ。Platformサービスはdockerコンテナ内で実行されるため、ExiftoolをコンテナにインストールしてGoアプリケーションから実行することができた。
func runExif(args []string) ([]byte, error) {
cmdOut, err := exec.Command("exiftool", args...).Output()
if err != nil {
return nil, err
}
return cmdOut, nil
}
Platformのもう1つのよくあるシナリオは、ソースCMSシステムからやってくる壊れたHTMLの取り込み、HTMLを有効であるようにパースすること、そしてHTMLのサニタイズだ。当初この処理にはGoが使われていたが、Goの標準HTMLライブラリは有効なHTMLインプットを想定しているため、サニタイズ前にHTML入力をパースするには大量のカスタムコードを必要とした。このコードはすぐに不安定になり、エッジケースを見落とすため、新しいソリューションをJavascriptで実装することにした。Javascriptのおかげで、HTMLの検証とサニタイズプロセスの管理に柔軟性と適用性が向上した。
Javascriptは、Platformにおけるイベントフィルタリングとルーティングにとっても一般的な選択肢だった。イベントは、呼び出された時のみ起動する軽量な関数であるAWS Lambdasでフィルタリングされる。1つのユースケースは、イベントを高速レーン、低速レーンという異なるレーンにフィルタリングすることだ。フィルタリングは、イベントラッパーJSONオブジェクトの1つのメタデータフィールドに基づいて実行される。フィルタリングの実装では、JSONオブジェクトの要素を取得するのに、Javascript JSON pointerパッケージを利用した。Goで必要だった完全なJSONのアンマーシャリングと比較して、このアプローチは非常に効率が良かった。Goでも実現は可能だったが、Javascriptを使う方がエンジニアにとって簡単であり、Lambdaもより単純になった。
Goのふりかえり
Contact Platformを実装して本番環境でサポートした今、GoとContent Platformのふりかえりをするなら、私からのフィードバックは次のようなものになっただろう。
うまくいったところは？
- 分散システムにとって重要な言語設計要素
- 比較的実装しやすい並行処理モデル
- 楽しく書けて、愉快なコミュニティ
改善できるところは？
- バージョニングとベンダー標準のさらなる進歩
- 一部の領域で成熟度が足らない
- 特定のユースケースで冗長
全体としてはポジティブな体験であり、GoはContent Platformをスケール可能にした重要な要素の1つだ。Goが常に適切なツールだとは限らないが、それで問題はない。The Economistはpolyglotプラットフォームであり、意味があるところでは様々な言語を用いている。テキストの塊や動的コンテンツをいじるとき、Goが最上の選択になることはないだろう。Javascriptがあるためだ。しかし、Goの強みは、システムをスケールさせ進化させることができるバックボーンであることにある。
Goが自分に適しているか検討するときは、システム設計に関する重要な問いを見直そう。
- システムの目標は何か？
- コンシューマにどんな保証を提供しているのか？
- どんなアーキテクチャおよびパターンがシステムに適しているのか？
- システムはどのようにスケールする必要があるのか？
もし、分散データ、非同期ワークフロー、高パフォーマンスおよびスケールリングという課題に取り組むことを目指したシステムを設計しているなら、Goについて検討し、どうすればシステムの目標を加速できるのか考えることをおすすめする。
著者について
Kathryn Jonas氏は現在、Teachers Pay Teachersでソフトウェアエンジニアとして働いている。その前は、The EconomistでContent PlatformのTech Leadとして働いていた。Jonas氏はBeijing、London、New Yorkの組織でプロジェクトをリードし、ミッションインパクト評価、編集の透明性と信頼性、オンライン学習とコラボレーションといった様々な課題に対して、技術を適用してきた。彼女の生きがいは、ソフトウェアアーキテクチャの議論に参加し、活力と能力のあるチームと仕事をすることだ。