テーマ:

みなさんこんにちは! エンジニアブログ運営チームの板敷です。

 

今回は、先日社内で行われたGo勉強会について紹介したいと思います。

今回の勉強会では、サイバーエージェントグループの各社から発表がありました。

 

勉強会ポスター。事前予約不要!

 

Golangの注目度は高く、開始即満員御礼でした。(若手中心に立ち見もw

 

 

それでは発表内容を紹介したいと思います。

 

※勉強会資料は社内情報が含まれているため全公開はできませんが、

勉強会の雰囲気だけでも感じ取っていただけると幸いです。

 

「Goトラップ ~中級者向けGo言語でよく引っかかる同期処理など周りの問題、分析と解決方法~」

技術本部 基盤システムG マリオさんの発表です。

 

※発表資料

https://github.com/imkira/gostudy

 

後述しますとおり、この他の発表内容は「サービスの中でGoをどのように使っているか」か話題の中心でしたが、

マリオさんの内容はGoを使う上で遭遇する言語仕様、または罠に関するもので、実際にコードを実行し修正しながらの発表という大変ユニークなものでした。

 

内容的には"Data Races”や”Deadlock”など、意識して書かないと当然Goでも発生しうるトラップについてでした。

 

新しく習得する言語だとついこの辺の考慮が漏れがちですからね。ありがたい共有となりました。

 

 

「GoでつくるAbemaTV」

続いてAbemaTVの西尾さんです。

 

注目度の高いサービスということもあり、開始直後にも関わらず会場の集中力は最高レベルでした。(当社比)

 

内容的には、golangのみならずマイクロサービスをベースとしたAbemaTVのシステム設計の話も多く、

これからgo + dockerなどを用いて設計する際の参考になるお話でした。

 

 

またKubernetesの読み方に関してはざわめきが起こることも予想されましたが、

「日本人なんで”クバネティス”と読む!」と言い切ってくれたので胸のモヤモヤが消えました。

 

「GAE/Goのススメ」

続いてアドテクスタジオ LODEOの池田さんです。

 

しょっぱな「Goの話し期待してると思うが、GAEが9割」の宣言から始まり

GAE/Go最強の理由を様々な観点から解説してくれました。

 

この発表でもgoの並行処理についての話があり、改めてそのメリットは大きいと実感させられました。

「みんなGAE興味ないかも知れないけど…」との言葉がありましたが、興味ある人が見に来ていますのでとてもよかったです!

 

「Go言語とDockerでAIバトル基盤を書いたら便利だった話」

次はアプリボット15新卒向井くん。

 

勉強会前に少し話したところ、本人的には実プロダクトでgoの経験がなく他の発表者と比べて内容が薄いかも知れないが、

せっかくの機会なんで思い切って話してみることにしました とのことでした。

 

この姿勢がすばらしいですね!

 

 

内容としては、アプリボット総会で使うAIバトル用に開発した「ボ◯バーマン風ゲーム」についてでした。アプリボットなんかすごいw

golangの特徴の一つである並行処理の書きやすさにも言及していました。

 

「10年物のレガシーPHPをGoにリプレイスしている話」

 

次はアドテクスタジオ CAリワード 平田さんです。

 

これまで支えてくれたレガシーシステムに圧倒的感謝をしつつ、Goに順次リプレイスするための設計の話が中心でした。

 

Goでは複雑なOOPは難しいのでシンプルな設計にする、テスタビリティを上げるためにinterfaceを積極利用、

ランタイムエラーを避けコンパイル時に気づくようにする など、今後Goでリプレイスする際には参考になるものばかりでした。

 

レガシーには悩まされたものの、「PHPには圧倒的感謝!(本人談)」の気持ちを忘れず今後もリプレイスを続けてくれることでしょう。

 

 

「クリラボにGo導入している話」

 

続いてアドテクスタジオ iXam Creative Lab. 水沼さんの発表です。

 

インフィード広告用のシステムにGoを導入したお話でした。

 

チームとしてGoを習得するために、毎週1~2時間Goの勉強会を実施したり、静的コード解析ツールをいくつかまとめ「Go養成ギプス」として導入するなど、チーム全体でGoに移行する際のヒントの多い発表となりました。

 

改めて、もくもく会は同じテーマだと捗りそうですねぇ。

 

「優秀な若手に狂奔するオッサン劇場 ~生き残りをかけて臨んだGoの道~」

まだまだ「Goへの移行ネタ」続きます! 続いてはアドテクスタジオ CAリワード 小高さんです。

 

ここまでの発表を聞いて、アドテクはほんとPHP多かったんだなという印象。同じ会社なのに意外と知らないことは多いものです。

 

レガシー化したPHPに悩んでいる中、優秀な若手とともにGoへの移行のお話でした。

にしても、最近の若手の優秀さは異常ですね・・・!

 

 

まとめ

以上がGo勉強会の紹介となります。

 

サイバーエージェントでは、社内外問わず日々勉強会等が行われており、

グループ各社の勉強会はじめ技術ネタは以下のブログでも発信されています。

よろしければご覧ください。

 

CAリワード TechBlo

アプリボット エンジニアブログ「てっくぼっと」

アドテクスタジオ TECH BLOG

 

 

そして最後に、サイバーエージェント&AbemaTVではGoエンジニアを募集しています。

興味のある方のご応募、下記よりお待ちしております!

 

サイバーエージェントキャリア採用

AbemaTVをネット発のマスメディアへ!GoエンジニアWANTED!

 

 

以上になります。

いいね!した人  |  リブログ(1)

テーマ:

こんにちは。Amebaの基幹系インフラ担当している鳥垣です。

 

ユーザーのサービス用途でElasticSearch(0.19.10)を使用しているのですが、先日ElasticSearchの障害で一部のShardが読めなくなってしまいまして、それを力技で無理やり読めるように復旧させたのでその時の奮闘記を記載したいと思います。

 

運用情報

  • 台数:30台
  • CPU:24コア
  • Heap:8GB
  • インデックス数:3
  • 総データ容量:約300GB
  • Shard数:128
  • レプリカ数:2
  • バージョン:0.19.10

※OpenStackの仮想サーバ

 

ホスト障害発生

  • OpenStackのホストサーバがダウンし、ElasticSearchのノードが1台ダウン。
  • Shardの再配置処理が走り、ダウンしたノードが持っていたShardは他ノードに分散される。
  • この時点ではElasticSearchのクラスタステータスはグリーンだった(Headプラグインで確認)。
  • ElasticSearchと連携しているAPIサーバ側からのElasticSearchヘルスチェックをしているのだが、そのチェックがfalseを返していた。

 

ホスト復旧

  • ホストサーバが復旧し、ダウンしていたElasticSearchノードサーバも起動したことを確認。
  • 他のホストサーバにマイグレーションする(またいつホストダウンするかわからないため)。

 

ノード復旧

  • マイグレーション完了後、ElasticSearchのプロセスを起動しクラスタに入れる。
  • Shardの再配置処理が走り、クラスタに無事Joinできたことを確認。
  • クラスタステータスもグリーンになっていることを確認。
  • しかし、APIサーバ側からのElasticSearchヘルスチェックがfalseを返していた。。
  • 以前別環境で運用しているElasticSearchでもAPIサーバ側のヘルスチェックでfalseを返していたときに全ノードを再起動して復旧させたことがあったため、今回も全ノードの再起動を実施する。

 

※これが悲劇の始まりでした。。

 

全台再起動

  • 1号機から順番に再起動を実施。ログファイルにてステータス確認しながら順次再起動していく。
  • 20台目までを再起動したあたりからAPIサーバ側にて遅延発生。
  • 再起動オペレーションを一旦中断。
  • HeadプラグインでElasticSeachのステータスが見れなくなる。。

※Shardの再配置処理が走りまくったせいでクラスタが不安定になりました。。。

  • 再び1号機から順番に全台再起動を実施。
  • Headプラグインでステータスが見れるようになる。
  • APIサーバ側の遅延解消し、ヘルスチェックもtrueを返すようになる。

 

しかし、ここで12個のShardがクラスタに戻らない事象が発生

その時のShard状態のキャプチャがこちらです。

 

 

※プライマリShardまでクラスタから外れてしまい、クラスタに戻ってくれない状態になってしまいました。。

※APIサーバ自体は遅延もおさまり運用できるようになりましたが、データが一部ロストしている状態になってしまいました。。

 

復旧検証

allocateコマンドを使ってunassignedになっているShardの移動を検討。

以下のようなコマンドで移動をやってみました。

curl -XPOST 'http://nodeIP:9200/_cluster/reroute' -d '{
  "commands": [{
  "allocate": {
  "index": "index name",
  "shard": 53,
  "node": "node host name",
  "allow_primary": false
  }
  }]
}'

結果:失敗 

エラーになり移動できませんでした。

 

Shardファイル確認

unassignedになってしまっているShardのファイルがどのように保存されているか確認してみました。

※ここでは3つのインデックスを仮にA,B,Cと呼称。

Aインデックス

Shard番号:53

状態:

  • 3,10,22,29号機にディレクトリを確認
  • ただしファイルがあるのは22号機のみ
  • 3,10,29号機のディレクトリは空状態

ステータスファイル:「A/53/_state/state-93」ファイルの中身

{
"version" : 93,
"primary" : false
}

※レプリカとして認識されていると予測。

 

Bインデックス

Shard番号:51

状態:

  • 27,28号機にディレクトリを確認
  • 両方にデータがあるがファイル内容が異なっている

ステータスファイル:「B/51/_state/state-108」ファイルの中身

{
"version" : 108,
"primary" : false
}

※レプリカとして認識されていると予測 。

※27号機にはステータスファイルはありませんでした。

 

Cインデックス

Shard番号:2,4

状態:

  • 27号機にのみ2番のディレクトリを確認
  • 25号機にのみ4番のディレクトリを確認

ステータスファイル:

「C/2/_state/state-427」ファイルの中身

{
"version" : 427,
"primary" : true
}

「C/4/_state/state-417」ファイルの中身

{
"version" : 417,
"primary" : true
}

※両方ともプライマリとして認識されていると予測

 

無理やり復旧させてみる

上記の状態を踏まえて、それぞれのShardを以下方法で無理やり復旧させてみました。

AインデックスのShard復旧手順

ファイルコピー

※対象ノードのElasticSerchプロセスを最初に停止しておく。

  • 22号機にのみファイルが残っているので、そのファイルをディレクトリのみ残っている3,10号機にコピーする。
  • 29号機のディレクトリは放置しておく(放置しておいても自然に削除されることを検証済み)。

ステータスファイルの書き換え

  • 22号機のみ「   "primary"   : false 」の箇所を「true」に変更する。
  • 3,10号機は「false」のままにする。

※上記作業を完了後、ElasticSeachプロセスを起動する。

※HeadプラグインでShardがクラスタに戻っていることを確認する。

 

BインデックスのShard復旧手順

このサイトを参考にlucene-coreを使ったインデックスチェックを実施してみる。

27号機のほうは壊れており、28号機のほうは正常であることを確認。

ファイルコピー

※対象ノードのElasticSerchプロセスを最初に停止しておく。

  • 27号機のファイルは壊れているので削除する。
  • 28号機のファイルを27号機と他ノードにコピーする。

ステータスファイルの書き換え

  • 28号機のみ「   "primary"   : false 」の箇所を「true」に変更する。
  • 他ノードは「false」のままにする。

※上記作業を完了後、ElasticSeachプロセスを起動する。

※HeadプラグインでShardがクラスタに戻っていることを確認する。

 

CインデックスのShard復旧手順

ファイルコピー

※対象ノードのElasticSerchプロセスを最初に停止しておく。

  • 2番Shardは27号機にのみファイルが残っているので、そのファイルを他の2ノードにコピーする。
  • 4番Shardは25号機にのみファイルが残っているので、そのファイルを他の2ノードにコピーする。

ステータスファイルの書き換え

  • 27,25号機のみ「   "primary"   : true 」のままにする。
  • コピーした他ノードは「false」に変更する。

※上記作業を完了後、ElasticSeachプロセスを起動する。

※HeadプラグインでShardがクラスタに戻っていることを確認する。

 

今回の反省

  • 再起動するときは自動再配置をOFFにしてから作業するべきでした。
  • 1ノードの再起動後はログファイルの確認だけでなく、再配置処理が完全に終了するのを見届けてから次のノードの再起動をするべきでした。

今後について

バージョンアップします!

Cassandraの面倒を見るのが大変だったので今まで大きな障害もなく放置していましたが、もうこんな古いバージョン使いつづけるのはやめます。。

 

今回の記事が、Shardが戻らなくなって困ったという悩みを抱えてらっしゃる方(あまりいらっしゃらないと思いますが。。。)のお役に立てれば幸いです。

 

いいね!した人  |  リブログ(1)

テーマ:

 

みなさんこんにちは。

 

技術組織戦略G & 技術内閣の板敷です。

普段はAmebaのシステム障害の火消し → 障害対策ならびにエンジニアの育成評価等をしています。

 

今回は、先日終了したサイバーエージェント新卒エンジニア技術研修について紹介したいと思います。

 

研修概要

従来の研修内容を一新、内製での技術研修に挑戦

 

これまでの新卒技術研修は委託先講師の話を新卒全員が聞くという、いわゆる「座学中心」の研修でしたが、ここ数年の技術的進歩、組織内でのエンジニアに対する期待の変化を反映するため、内製での研修へとゼロから再設計しました。

 

 

研修のコンセプトと概要

ベースとなる研修のコンセプトは以下2点からなります。

  1. 全体のアーキテクチャを俯瞰して設計、技術選定をする
  2. 自分の頭で考え、動く

これらのコンセプトを実現するために今回の研修では、2つの某有名サービスを

自分たちで設計、実装するという形をとりました。

 

研修詳細

次に研修全体の流れに沿って、詳細内容を紹介します。

 

以下1~6の流れをお題を変えて2回繰り返すことで、1回目の反省を2回目に活かせる設計としました。(新卒だけではなく、運営側もw)

 

1.お題、レギュレーション、チーム分け発表

 

■お題

1回目は某有名SNSサービス、2回目は某有名検索エンジンの開発としました。

 

■開発レギュレーション

レギュレーションは機能面、性能面、コスト面の3軸からなります。

 

機能面

 ・投稿ができる、フィードが表示される、お気に入りができるなど(SNSサービス)

 ・and, or , not検索ができる、検索結果の関連度/適合率/網羅性など(検索エンジン)  

 

性能面

 ・40万フォロワーのいるユーザが投稿してからN秒以内にフォロワーのフィードに反映される(SNSサービス)

 ・継続的に検索結果がN秒以内に返ってくる(検索エンジン)

 

コスト面

 ・開発中のインスタンスコストを$300程度に抑える(今回はAWSを利用)

 

■チーム分け

・各チーム4名(一部3名)で構成。

・基本的に得意技術がバランスよくなるようなチーム分けを目指しました。

 

 

2.設計コンセプト、技術選定

次にお題、レギュレーションを踏まえ設計コンセプト、技術選定を行います。

 

 

※以下実際の例

 

設計コンセプト

・「疎結合で可搬性の高い、スケーラブルなアーキテクチャ」

技術選定

・Go, Python, AngularJS2, Elasticsearch, Docker, Kubernetes, GRPC, Terraformなど

 

設計コンセプト

・「完全に真似るのではなく遊び心を取り入れ楽しいアプリケーションを作る」

技術選定

・Unity, Scala, PlayFrameworkなど

 

設計コンセプト

・「自分達が慣れていなくても良いものを選ぶ」

技術選定

・Go, React.js, Webpack, ECS, Elastisearchなど

 

設計コンセプト

・「堅実な言語で実際の開発を意識し、コードやデザインパターンはモダンな仕様で設計」

技術選定

・Java, SpringBoot, Apache, Tomcat, MySQL, Swift, Realmなど

 

 

などなど。

チャレンジのいい機会としてモダンな技術を選択したチーム、完成度重視で扱い慣れた技術を選択するチームなど個性がはっきりと現れました。

 

 

3.役割決め、スケジュール作成

 

実際の開発に入る前に、役割を決めスケジュールを引きます。

 

1回目のお題時は見積もり精度が低かったり、得意なものからとりあえず実装、 というチームも見られましたが、2回目は開発する機能、メンバーのスキルセット踏まえた進め方へと大きく改善していました。

 

また2回目の開発では、従来クライアントしかやったことのないメンバーもサーバサイド担当になるなど、今回の研修ならではのチャレンジも見られました。

 

 

4.開発スタート

 

スムーズに開発がスタートできたチームもあれば、サンプルデータの投入でハマったチーム、技術選定の失敗に気づき1からやり直すチームなど、機能開発以前でのつまづきも見られましたが、毎日1時間メンタータイムとして先輩エンジニアがフォローすることでこれらを乗り越えました。(メンターのみなさんありがとう!)

 

 

 

5.中間発表     

 

各チームの進捗や設計/実装内容を発表、メンターからのフィードバックを受け軌道修正を行います。

 

1回目のお題では2度の中間発表を設けましたが、2回目は難易度を上げるため、中間発表を1度のみにするなど難易度調整にも役立ちました。

 

 

6.最終プレゼン

 

各チーム最終成果物を発表。 設計コンセプトやアピールポイントなど発表しつつデモンストレーションをし、審査員からの質問に答えます。

 

実装した機能の完成度はもちろん、スライドのクオリティも予想よりはるかに高く、

「最近の若手はなんでこんなに優秀なんだ」と一回り以上離れた新卒を見ながら改めて感じさせられるイベントでした・・・。

 

また最終プレゼンを受け、いくつかの賞の発表も行いました。

ベストクライアント賞、ベストアーキテクチャ賞、ベストサーチエンジン賞など。

 

研修振り返り&まとめ

今回は内容面でも運営面でも従来の方針を一新し、ゼロからの再設計となりましたが、全体としてはおおむね上手く行き、またいいチャレンジができたと感じています。

 

新卒の技術研修というのはエンジニアとしてのスタートでもあるので、最初だからこそ意識してほしいことや、チャレンジしてほしいことを実現するための研修を心がけました。

 

一方、研修後の振り返りでは課題も多く見つかったので、来年に向けてはこれらを解決する方法を取り込みながら、事業・技術・組織の変化に合わせて研修もアップデートしていければと思っています。

 

 

以上が今回の新卒エンジニア技術研修の紹介となります。

サイバーエージェントの技術研修に興味を持ってくれた学生のみなさん、ぜひコチラからエントリーしてみてくださいね!

 

お会いできるのを楽しみにしています。

以上です。

 

いいね!した人  |  リブログ(2)