TypeScriptでNodeのWebアプリを書き換え中
今年頭からNode.jsを本格的に初めてみて、JavaScriptの柔軟性の便利さと怖さに四苦八苦してしてます。と言っても、1/3ぐらいは負荷試験してたり、細々と色々なことしてたので、そこまで書いてたわけではないけど。
オブジェクトにどんどんプロパティを追加して柔軟にできたり、ちょこっと関数追加できたりと嬉しい恩恵もあるのですが、その一方でこの関数の引数/戻り値の型がわからなかったりして、TypeErrorを連発してしまって、Java1.4時代のClassCastExeceptionの時代に戻ってしまった思いをしてます。 自分はIDEを使ってるのですが、その恩恵が100％得られてないというお金的に損した気分。
で、まぁ自分のベースはJavaなので型がある言語だと嬉しいよね。ということで、ちょっと前からTypeScriptの勉強を始めてます。型以外にもES6ぽい書き方もできるし、TypeScriptが出力するJSコードを見つつ、JSの勉強もするという色々なことに使ってます。
GW中にガッツリ書き書き換えて久しぶりにコード書いて徹夜して、自分でもまだまだいけるんだと自己満足に浸っております
通称わかめ本を読みつつ、以前Nodeを勉強するときに作ったWebアプリをTypeScriptで書き換え中。大規模開発になってるので実際の新規プロダクションで入れられたらいいなー
今はまだ書き換えてる途中なので、所々お作法に沿ってなかったりします。 [TypeScript版] https://github.com/hachi-eiji/79school-2/tree/typescript [通常のJavaScript版] https://github.com/hachi-eiji/79school-2/tree/master
まぁ一番間違っているのは二重コールバックのコードをよく書いてしまってることだけどw
- 作者: わかめまさひろ,井上章,丸山弘詩
- 出版社/メーカー: インプレスジャパン
- 発売日: 2014/05/16
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
自分用のメモにもslackがいいのかもしれない
仕事用のメモで何かいいのないのかなーと色々試している途中
ユースケース
- メモはほぼ毎日書く
- 自分用のミーティング議事メモや、軽いプログラム(集計SQLとかコピペで実行するシェルとか)、コード書いてて気づいたことを書く。
- 小さなタスクも書く
- ホワイトボードをカメラで撮ることはある
必須要件
- プロジェクト情報とか入るので、自分以外には見せたくない
- マシンが複数台(会社と家に障害対応用マシン)あるので共有はしたい
- メモの書き出しには日付入れてわかりやすくしたい
あったら嬉しい
- 過去に書いたものを検索する
- 可能な限りテキストベースでコピーとかしたい
- vimコマンドでショートカットできると嬉しい
- インターネットにつながってなくても使えると嬉しい
- markdown でかけると助かる
やらなくていいこと
- スマホからのアクセス
- 自分用のメモなので細かいバージョン管理
| 試したもの | 感想 |
|---|---|
| テキストファイル | DropboxとかGitを使って同期できる。 数年使っていたが、月ごとにファイル分けるのがだんだんめんどくさくなってくる。 Dropboxには他の大きなファイルがあるのでスペックが低い障害対応用マシンで同期するのはディスクサイズを食うので、GitHubを使ったが毎日pushするのめんどくさい |
| Evernote | PC、スマホ用のクライアントアプリある コピーするとHTMLタグ(？)を自動で設定するのですごい不便。 プロジェクトの仕様とかをガッツリまとめるには便利。1週間ぐらい使って止めた。 |
| Kobito | QiitaのMac版クライアントアプリ。有料プランにするとDropbox同期ができる。 markdownのリアルタイムプレビューもあるので、有料でもいいかなと思ってたが、1ヶ月(実際は20日営業日前後)書いてるとクライアントアプリが明らかに重くなった |
| wri.pe | ノートを取るシンプルなWebサービス。markdownで記載できて、リアルタイムプレビューができる。auto saveもしてくれるのは嬉しい。 時系列に書くので、最新のものを一番上に書いているが、テキストエリア内の最初のフォーカスが一番下に来てるのがすごい惜しい。もし、フォーカスが一番下に来るのであれば、markdownプレビューも一番下に来てほしい。あとmarkdownのプレビュー文字が小さいのでもう少し大きくしてほしい。 |
| Slack | テキスト形式ではないものの投稿したら自動で時系列になる。コードスニペット書けるし、画像もアップできる。 タスクはstarで管理しておく。今のところあまり不満はない。 ちなみにChatWorkでもできるかなと思ったがSlackのほうが機能多かった。ただ、タスク機能は恐ろしく便利。社内のチャットツールがChatWorkだったら全部まとめてた。個人的にはHipChatよりChatWorkのほうが好き(期待値も込めて) |
ということで、今のところSlackに落ち着いてる。もうすこし使ってみて、使い方あってなかったらwri.peにするかChatWorkにするかも。いいものがあれば教えてくれるとすごい嬉しいです
gulpを書くときのメモ
背景
今のプロジェクトでgulpの中身を見ることが何回かあって、そのたびに「こうしたらいいのになー」とか思うので、軽くまとめておく。見るたびに直したい衝動にかられるが、動いているのには理由があるし、今はそのフェーズでないのでグッと我慢する。もちろんgulpを書いてる人から見たら、全部gulpを見ればわかるとか、ファイル分割されているとか、いいところはあるんだろうけど。 当たり前のことを書いてるが、自分が忘れやすいのでメモってるだけ
今回のユースケース
実際のプロジェクトではもっとたくさんのことをやってるが今回は下記に絞る
- ローカル環境もしくはJenkins上から呼び出す。
- JavaScript(CSS)ファイルをminifyしたり、画像をリサイズする。
改善点メモ
- 本番環境,開発環境でminifyする/しないをわけない。タスクをまとめた親タスクを作るか、呼び出し側で制御する。親タスク側ではminimistとかつかって、外部パラメータを渡す。開発環境は何台でも増えるし、いままでminifyしてなかった環境でminifyしたくなることもある
- gulp-helpを使ってタスクの説明を書く。3日後の自分は他人 gulp-help
- ファイルを分割しすぎない。gulpfile.js → ファイルA.js → ファイルB.js→ファイルA.jsに戻るみたいなことがあった。若干冗長でも2つ目ぐらいで止めておきたい
なんかこんな感じ
$ gulp help [00:52:46] Using gulpfile ~/development/gulp-test/gulpfile.js [00:52:46] Starting 'help'... Usage gulp [task] Available tasks help Display this help text. minify-js JavaScriptをMinifyします [00:52:46] Finished 'help' after 1.5 ms
UNIXという考え方の本はこういうときも役に立つ
- 作者: Mike Gancarz,芳尾桂
- 出版社/メーカー: オーム社
- 発売日: 2001/02
- メディア: 単行本
- 購入: 40人 クリック: 498回
- この商品を含むブログ (140件) を見る
MongoDBのindex
indexの作成
db.collection_name.ensureIndexで作成できる。この時に第2引数のoptionsにbackgroundを入れること。デフォルトは background:falseなので、index作成完了までデータベースロックがかかるため
ちなみにバックグラウンドを有効にした場合でも、シェルセッションの応答まではバックグラウンドにならない.
なお、性能はバックグラウンドで作成したほうが遅い。
バックグラウンドで作成するときは,primary終了後にsecondaryへindex作成が行われるので、primary -> secondaryの順番で作成する。
secondaryで大きなindexを作成するときは、一度secondaryを外したのちに単独でindexを作成する.再度レプリカセットに入れるときに他のセカンダリにキャッチアップできるようにしてから、stepDownでプライマリを切り替える。Build Indexes on Replica Sets — MongoDB Manual 3.0.1に書いてあったけど、変更したReplica SetのステータスがRECOVERINGで止まった。(別セッションでinsertしてるからどんどんprimaryとずれていくのはわかるけど...)
この辺は詳しい方に教えていただきたい
複合index
{ "item": 1, "location": 1, "stock": 1 } というindexを貼った場合は、検索条件でindexを使わない場合がある(基本MySQLと同じかな)
| 検索条件 | index使う？ |
|---|---|
| item | o |
| item, location | o |
| location, item | o |
| item, location, stock | o |
| item, stock | o (ただし、item,stockでindexを貼ったほうが効果はある) |
| location | x |
| stock | x |
| location, stock | x |
sortでindexを使う場合
{a:1, b:1}というindexを貼った場合はクエリの条件で { a: 1, b: 1 },{ a: -1, b: -1 }とした場合にはindexは見るが、{b:1, a:1},{a:-1, b:1}の場合は見ない。検索条件とsortを同時に使用する場合は、作成したindexの並び順通りになる。(MySQLとかと同じだとおもう)
Index Intersection
1クエリで複数indexを使うようになった.複合indexとの性能の違いはあまり見つけられず...
Sparse Indexes
指定されたプロパティが存在しない時に無視されるindex。今のところ通常indexと混在すると色々面倒そうな気がするので、あまり使い道が出てこない
mongos> db.scores.save({userid:"newbie"});
WriteResult({ "nInserted" : 1 })
mongos> db.scores.save({userid:"abby", score: 82});
WriteResult({ "nInserted" : 1 })
mongos> db.scores.save({userid:"nina", score: 90});
WriteResult({ "nInserted" : 1 })
mongos> db.scores.ensureIndex({score :1}, {sparse:true});
{
"raw" : {
"ip-10-0-0-16.ec2.internal:27017" : {
"createdCollectionAutomatically" : false,
"numIndexesBefore" : 1,
"numIndexesAfter" : 2,
"ok" : 1
}
},
"ok" : 1
}
mongos> db.scores.find( { score: { $lt: 90 } } )
{ "_id" : ObjectId("54a7988e5a355747582911e1"), "userid" : "abby", "score" : 82 }
mongos> db.scores.find().sort( { score: -1 } )
{ "_id" : ObjectId("54a798995a355747582911e2"), "userid" : "nina", "score" : 90 }
{ "_id" : ObjectId("54a7988e5a355747582911e1"), "userid" : "abby", "score" : 82 }
{ "_id" : ObjectId("54a798805a355747582911e0"), "userid" : "newbie" }
mongos> db.scores.find().sort( { score: 1 } )
{ "_id" : ObjectId("54a798805a355747582911e0"), "userid" : "newbie" }
{ "_id" : ObjectId("54a7988e5a355747582911e1"), "userid" : "abby", "score" : 82 }
{ "_id" : ObjectId("54a798995a355747582911e2"), "userid" : "nina", "score" : 90 }
mongos> db.scores.find().sort( { score: -1 } ).hint( { score: 1 } )
{ "_id" : ObjectId("54a798995a355747582911e2"), "userid" : "nina", "score" : 90 }
{ "_id" : ObjectId("54a7988e5a355747582911e1"), "userid" : "abby", "score" : 82 }
mongos> db.scores.ensureIndex({score :1});
{
"raw" : {
"ip-10-0-0-16.ec2.internal:27017" : {
"createdCollectionAutomatically" : false,
"numIndexesBefore" : 1,
"numIndexesAfter" : 2,
"ok" : 1
}
},
"ok" : 1
}
mongos> db.scores.find( { score: { $lt: 90 } } )
{ "_id" : ObjectId("54a7988e5a355747582911e1"), "userid" : "abby", "score" : 82 }
mongos> db.scores.find().sort( { score: -1 } )
{ "_id" : ObjectId("54a798995a355747582911e2"), "userid" : "nina", "score" : 90 }
{ "_id" : ObjectId("54a7988e5a355747582911e1"), "userid" : "abby", "score" : 82 }
{ "_id" : ObjectId("54a798805a355747582911e0"), "userid" : "newbie" }
mongos> db.scores.find().sort( { score: 1 } )
{ "_id" : ObjectId("54a798805a355747582911e0"), "userid" : "newbie" }
{ "_id" : ObjectId("54a7988e5a355747582911e1"), "userid" : "abby", "score" : 82 }
{ "_id" : ObjectId("54a798995a355747582911e2"), "userid" : "nina", "score" : 90 }
mongos> db.scores.find().sort( { score: -1 } ).hint( { score: 1 } )
{ "_id" : ObjectId("54a798995a355747582911e2"), "userid" : "nina", "score" : 90 }
{ "_id" : ObjectId("54a7988e5a355747582911e1"), "userid" : "abby", "score" : 82 }
{ "_id" : ObjectId("54a798805a355747582911e0"), "userid" : "newbie" }
シャーディングの復習
シャーディングの種類
- Range Base sharding
- Hash Base Sharding
- 全部のshardに分散されるので均一的にデータが入る
- 範囲検索するとおそらくすべてのshardにアクセスするとおもうので微妙
- データ一本釣りするときは有効かもしれない。(例:ユーザ自分自身のデータを引っ張ってくるときとか)
- Tag Aware Sharding
- 「タグ」をshard keyにするぽい
下2つは2.4以降に追加されたけど、今のところうまい使い道が出てこないのが残念なところ
シャーディングをくむ
基本MongoDBのSharding機能で遊ぶ - 個人的なまとめで作ってる通りです。今回は設定ファイルをyamlファイルにしたぐらい。
コレクションの初期配置のshardingを変える
sh.shardCollection でシャーディング対象のコレクションを追加した後に、moveChunkするだけ。最初のマイグレーションが走る前はprimary shardに入るので、こうやってprimary shardにデータが偏らないようにします。
mongos> sh.shardCollection("test.fuga",{id:1})
{ "collectionsharded" : "test.fuga", "ok" : 1 }
mongos> printShardingStatus()
--- Sharding Status ---
databases:
{ "_id" : "test", "partitioned" : true, "primary" : "shard0000" }
test.fuga
shard key: { "id" : 1 }
chunks:
shard0000 1
{ "id" : { "$minKey" : 1 } } -->> { "id" : { "$maxKey" : 1 } } on : shard0000 Timestamp(1, 0)
mongos> sh.moveChunk("test.fuga", {id: {$minKey:1}}, "shard0001");
{ "millis" : 82, "ok" : 1 }
mongos> printShardingStatus()
--- Sharding Status ---
databases:
{ "_id" : "test", "partitioned" : true, "primary" : "shard0000" }
test.fuga
shard key: { "id" : 1 }
chunks:
shard0001 1
{ "id" : { "$minKey" : 1 } } -->> { "id" : { "$maxKey" : 1 } } on : shard0001 Timestamp(2, 0)
チャンクを分割したい
データが集中してチャンクを分割して移動させたいときはsh.splitFind()で中央で分割させます。sh.splitAt()もありますが、均等な分割をさせたほうがマイグレーション的に優しいです。基本、MongoDBに任せたほうがいいのですが、運用途中で分割させないといけないケースが出てるので。必要であれば、moveChunkします。
mongos> printShardingStatus()
--- Sharding Status ---
test.test_collection
shard key: { "user_id" : 1 }
chunks:
shard0002 2
shard0000 3
shard0001 3
{ "user_id" : { "$minKey" : 1 } } -->> { "user_id" : 0 } on : shard0002 Timestamp(7, 1)
{ "user_id" : 0 } -->> { "user_id" : 5999 } on : shard0000 Timestamp(8, 1)
mongos> sh.splitFind("test.test_collection", {user_id: 0});
{ "ok" : 1 }
mongos> printShardingStatus()
--- Sharding Status ---
databases:
{ "_id" : "test", "partitioned" : true, "primary" : "shard0000" }
test.test_collection
shard key: { "user_id" : 1 }
chunks:
shard0002 3
shard0000 3
shard0001 3
{ "user_id" : { "$minKey" : 1 } } -->> { "user_id" : 0 } on : shard0002 Timestamp(7, 1)
{ "user_id" : 0 } -->> { "user_id" : 2999 } on : shard0002 Timestamp(9, 0)
{ "user_id" : 2999 } -->> { "user_id" : 5999 } on : shard0000 Timestamp(9, 1)
コンソール触ってて気づいたこと
- tabキーを押すと補完が効いたけど、昔からあった？？
- sh,rsから始まるコマンドあったっけ？db.runCommandで実行してたけど、いつから入ったんだろうか？
- ctrl+rで過去に実行したコマンド検索できるようになってる
MongoDBのバックアップ周りを実際にやってみる
2年ぶりにMongoDBを触ることになったので、リハビリがてらReplica SetとSharding周りを触ってます。
とりあえず今日はReplica Setとバックアップ周り。
なぜバックアップまわりかというと、前に触ってた時は本当に基礎部分しかやってなかったので、バックアップ方法などはあまりチェックしてなかったためです。
日付が一番新しかったのが CyberAgentにおけるMongoDB のスライドだったので、この方法でやってみようかなと。(はてなダイアリーってslide shareって埋め込みできなかったのね)
arbiterとnovoteにしている理由がはっきりしなかったのですが、わざわざTwitterで回答を頂きました。ありがとうございました。
@hachi_eiji これは現状綺麗にクラスタのバックアップを取るのに、同時にmongodのプロセスを落とすのが一番手軽な為です。落としても問題ない様にnovoteにしてます。で、バックアップ中にRSのもう一台が落ちるとクラスタダウンなのでarbiter入れてると言うわけですー
— Akihiro Kuwano (@kuwa_tw) 2014, 12月 30ということで実際にやってみます。
Replica Setをくむ
ReplicaSetで遊ぶ - 個人的なまとめ で Replica Setを組む方法はすでに知ってるのですが、MongoDB 2.6.6になってから色々変わっていると思ったので、再度ドキュメントを見なおしてみました。
そしたらconfigファイルのフォーマットがYAMLになっててびっくり。でも、これってなんか意味があるんだろうかと謎。まぁ、設定が構造として表現できるから楽になるのかな？ぐらい。
サーバ構成としては、3台サーバを用意して、その中の1台にarbiter用のmongodを設定しました。設定ファイルは下記にまとめてます。
最初にmongodを立ち上げた後に、arbiterを立ち上げて、rsコマンドでarbiterを追加するところまでは順調に行ったので、これで試せる状態になりました。
バックアップ対象のmongodを落としたあとに、他のprimaryやsecondaryを落とした時にもちゃんとサービスが継続できるかというのが確認ポイントです。
早速やってみる。
初期状態(rs.status()の一部抜粋)
| id | 状態 | 備考 |
|---|---|---|
| 1 | SECONDARY | |
| 2 | SECONDARY | バックアップ対象のサーバ |
| 3 | PRIMARY | |
| 4 | ARBITER |
_id2のmongodを落とす
| id | 状態 | 備考 |
|---|---|---|
| 1 | SECONDARY | |
| 2 | (not reachable/healthy) | バックアップ対象のサーバ |
| 3 | PRIMARY | |
| 4 | ARBITER |
ここで_id:1のsecondaryのプロセスを落とす
| id | 状態 | 備考 |
|---|---|---|
| 1 | (not reachable/healthy) | |
| 2 | (not reachable/healthy) | バックアップ対象のサーバ |
| 3 | SECONDARY | |
| 4 | ARBITER |
あれ？全部secondaryになった ( ﾟдﾟ)ﾎﾟｶｰﾝ
あ、novoteの設定入れてない。vote(投票権)の全体数の過半数の票を取らないといけないのに、全体の半数になったからだ orz
rs.reconfigで設定します。(reconfigを実行するとrs.stepDownが走るので気をつけましょう)
rs:SECONDARY> rs.config()
{
"_id" : "rs",
"members" : [
{ "_id" : 1, },
{ "_id" : 2, "votes" : 0 },
{ "_id" : 3, },
{ "_id" : 4, "arbiterOnly" : true }
]
}
rs:SECONDARY> rs.status();
{
"members" : [
{ "_id" : 1, "health" : 1, "state" : 2, "stateStr" : "SECONDARY", },
{ "_id" : 2, "health" : 1, "state" : 1, "stateStr" : "PRIMARY", },
{ "_id" : 3, "health" : 1, "state" : 2, "stateStr" : "SECONDARY", },
{ "_id" : 4, "health" : 1, "state" : 7, "stateStr" : "ARBITER", }
],
}再度、バックアップ対象サーバのmongodを落とそうと思ったのですが、stepDownが走った時に該当サーバがprimaryになってるじゃありませんか。
ということで、バックアップ対象サーバのpriorityを0にして、primaryにならないようにしました。
最初はprimaryにしない設定をした時に悪影響出るかなと思ったのですが、どちらにしてもバックアップ対象以外で2つ落ちたら、クラスタがダウンするので、こちらのほうがシンプルかなと思いました。(あえてmongodも冗長化するのであれば、novotesかつpriorityが0ではないsecondaryを追加するとかぐらいですかね...未検証ですが)
ちなみに2.6からvoteの値は1より大きい値を設定すると警告がでます。[http://docs.mongodb.org/manual/reference/replica-configuration/#local.system.replset.members[n].votes]
rs:PRIMARY> rs.config()
{
"members" : [
{ "_id" : 1, },
{ "_id" : 2, "votes" : 0, "priority" : 0 },
{ "_id" : 3, },
{ "_id" : 4, "arbiterOnly" : true
}
]
}最終的にはこういう状態でバックアップスタート
| id | 状態 | 備考 |
|---|---|---|
| 1 | SECONDARY | |
| 2 | SECONDARY | バックアップ対象のサーバ votes:0(投票権がない), priority:0(primaryにならない) |
| 3 | PRIMARY | |
| 4 | ARBITER |
バックアップ対象サーバのmongodを落とす
| id | 状態 | 備考 |
|---|---|---|
| 1 | SECONDARY | |
| 2 | (not reachable/healthy) | バックアップ対象のサーバ votes:0(投票権がない), priority:0(primaryにならない) |
| 3 | PRIMARY | |
| 4 | ARBITER |
id:1(secondary)のmongodを落とす
| id | 状態 | 備考 |
|---|---|---|
| 1 | (not reachable/healthy) | |
| 2 | (not reachable/healthy) | バックアップ対象のサーバ votes:0(投票権がない), priority:0(primaryにならない) |
| 3 | PRIMARY | |
| 4 | ARBITER |
id:1のmongodを立ち上げた後、id:3(primary)のmongodを落とす
| id | 状態 | 備考 |
|---|---|---|
| 1 | PRIMARY | |
| 2 | (not reachable/healthy) | バックアップ対象のサーバ votes:0(投票権がない), priority:0(primaryにならない) |
| 3 | (not reachable/healthy) | |
| 4 | ARBITER |
id:3のmongodを立ち上げた後、id4(arbiter)を落とす
| id | 状態 | 備考 |
|---|---|---|
| 1 | SECONDARY | |
| 2 | (not reachable/healthy) | バックアップ対象のサーバ votes:0(投票権がない), priority:0(primaryにならない) |
| 3 | PRIMARY | |
| 4 | (not reachable/healthy) |
とりあえず、バックアップの設定はできた。本当はMMS: The easiest way to run MongoDB | Cloud managed MongoDB on the infrastructure of your choiceとか使うほうがいいんだろうけどなー
設定ファイル
mongod.conf
systemLog: destination: file path: "/var/log/mongodb/mongodb_s1.log" logAppend: true storage: journal: enabled: true smallFiles: true dbPath: "/data/db/s1" processManagement: fork: true net: port: 27017 replication: oplogSizeMB: 10 replSetName: rs
arbiter.conf
systemLog: destination: file path: "/var/log/mongodb/arbiter.log" logAppend: true storage: journal: enabled: false smallFiles: true dbPath: "/data/arb" processManagement: fork: true net: port: 30000 replication: oplogSizeMB: 10 replSetName: rs
JDK7→JDK8にバージョンアップした時の作業まとめ
12/25 追記
JDK8でmaven releaseプラグイン経由でJARを生成するときにjavadocを作成しててエラーになった。
maven-javadoc-pluginのconfiguration <additionalparam>-Xdoclint:none</additionalparam>
を追加した
サーバ構成
インフラの構成ファイルはchefで管理
- アプリケーションサーバ 約50台
- jetty + Spring Framework 3.2.4
- バッチサーバ 2台
- Jenkins + Spring Framework 3.2.4
当初の予定
以前、他メンバーがJDK8にアップデートできるか検証してくれていて、NewRelicが対応していなかったため断念したという経緯があったので、そんなに変更が無いだろうと判断。
- 開発環境で軽く検証
- サーバ1台にJDK7でコンパイルしたwarをJDK8上で動くか検証する。問題があれば即座にロードバランサーから切り離す。
- NewRelicやMunin,Zabbixの確認
- 問題なければ全サーバへJDK8をアップデート(アプリはJDK7でコンパイル)
- JDK8でコンパイルしたアプリをデプロイする (←ここはまだ)
もちろんすべての動きを開発環境で確認できるのがベストだが無理かつ、他システムと連携している部分は最終的には本番環境でしか確認できない。
よって、実際に稼働しているサーバに入れて、ログを監視して問題があれば、ロードバランサーからサーバを切り離してユーザがアクセス出来ないようにする方針を取った。
開発環境上でハマったところ
- コンパイルが通らない
- lombokのバージョンが古かったので最新にバージョンアップ
- テストがコケる
- Jenkins(Version 1.555)がJDK8で起動しない
- Jenkinsを最新に変更した
Springのバージョンアップが入った時点で予定変更
本番環境へ入れてみてハマったところ
性能/JVMパラメータ
JDK7でコンパイルしたアプリをJDK8上で動かしても特に性能落ちていない。
JVMパラメータなどはPermSize→MetaspaceSizeに変更して、MaxDirectMemorySizeを追加したぐらいで、G1GCは入れてない。
問題が起きた時に何が原因かわからなくなるので、変更は最小限にしたかった。
G1GC導入は他の優秀なエンジニアがやってくれるはず|дﾟ)ﾁﾗｯ
感想
- 当初、他作業と平行してやろうと思ってたが、やっぱり無理だったので、この作業だけに専念できたのは大きかった
- 社内のプライベートクラウドが便利だった。一人あたり5CPU分つかえたので、JDK7とJDK8を入れたサーバを用意して、それぞれで問題ないか検証してた。
- SpringのバージョンアップCVE-2014-3578 Directory Traversal in Spring Frameworkの問題が見つかったので、Springのバージョンを3.2.12にあげて正解だった。
参考にしたもの
- 作者: 山口徹,Jxck,佐々木大輔,横路隆,加来純一,山本伶,大平武志,米川健一,坂本登史文,若原祥正,和久田龍,平栗遵宜,伊藤直也,佐藤太一,高橋俊幸,海野弘成,五嶋壮晃,佐藤歩,吉村総一郎,橋本翔,舘野祐一,中島聡,渡邊恵太,はまちや2,竹原,河合宜文,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2014/08/23
- メディア: 大型本
- この商品を含むブログ (1件) を見る
![Software Design (ソフトウェア デザイン) 2014年 10月号 [雑誌]](http://ecx.images-amazon.com/images/I/51gMA6BhkEL._SL160_.jpg "Software Design (ソフトウェア デザイン) 2014年 10月号 [雑誌]")
Software Design (ソフトウェア デザイン) 2014年 10月号 [雑誌]
- 出版社/メーカー: 技術評論社
- 発売日: 2014/09/18
- メディア: 雑誌
- この商品を含むブログ (4件) を見る
