ISUCON 4にチーム「ヤキトリ缶(タレ)」で参加したが、いまいちパッとしない感じだった #isucon
先週開催されたISUCON4に、去年に引き続き参加してきました。
チームメンバーは去年と同じ@hisayoshと@qtkmz。チーム名は、去年に引き続きチームミーティングした時に目の前にあった食べ物です。ちなみに去年のチーム名は「勝浦タンタンメン」。
参加日は1日目、仕様言語は去年に引き続いてPython。Goが有利みたいな高度な情報戦も流れていたのですが、去年、Pythonで勝てなかった悔しさから今年もPythonで再挑戦と決めていので、特に言語選択では迷いませんでした。
結果
結果から言うと、タイトルの通りいまいちパッとしない感じで、予選時に提出したスコアは30000弱。予選1日目からベンチマークに見直しがかかったので、更新後のBenchmark v2で、後日確認したスコアはだいたい35000。最終結果の発表は、10/6(月)なのでまだわかりませんが、予選通過ラインには届かなさそうな気配。
今回やったこと
今回やれたこと/やろうとしてやりきれなかったことをざっくり。
- やれたこと
/etc/sysctl.conf net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 30 net.ipv4.ip_local_port_range = 10000 65535
- やりきれなかったこと
前回のISUCON3の予選では、結果として予選の環境とベンチマークに特化したスコア稼ぎで予選を突破してしまった*1ので、今回は普通のチューニングで着実にスコアを上げていく方向で進めたのですが、いろいろ手間取っているうちにタイムアップ。
飛び道具には手を付けず、とはいえ、超絶アプリ改修もなしの至って普通のチューニングです。
自分たちのチームではこの程度のチューニングができれば予選は通過できると踏んでいたのですが、フタを開けてみると今年は去年以上にレベルが上がっていて、4万以上のハイスコアを出すチームが多数。その勝負の舞台に乗りきれなかった感じです。この辺りの読みと判断も含めてISUCONの勝負なんですよね。。。
当日までの流れ
対策ミーティング
僕たちのチームメンバーは、会社もバラバラで一緒に開発した経験もないため、去年のISUCON本戦ではお互いのやっていることがバッティングしたり、開発方針を共有したりするのに手間取ったので、一旦メンバーで集まって、去年のISUCON予選の問題を題材にして、チーム開発の方法を確認。実質的にはGithubハンズオンで、Mergeリクエストベースで開発することを決めて手順確認。
参加者ブログを見ると、1台のサーバ上のファイルを書き換えたという侠気あふれる報告もありますが、それができるのはいつも一緒に作業してて、阿吽の呼吸があるからだと思うんですよねー
なので、一手間かかりますが、Mergeリクエストを送って、各人が編集内容を確認できるようにしました。
去年のISUCONブログを見ても、役割分担を完全に決めてしまって、それぞれの作業は見ないで進めたって話がほとんどなんですが、即席チームだとなかなかそうも行かず。
本当はもっと対策ミーティングをやったり、ミドルウェア系の秘伝のタレを用意したりしたかったのですが、結局なかなか集まる時間を取ることができず、ISUCONがあった週は自分が毎日終電を逃すスパイラルに陥っていたので、最低限の開発手順と視点の共有ぐらいの準備で本番に臨みました。
当日の流れ
当日の流れを箇条書きで。
- まずはAMIを起動して、アプリ確認。銀行アプリかと見せかけたログインするだけのアプリ。
- ベンチマークを掛けてみる。MySQLの負荷が高い。
- 開発環境として、メンバーごとにインスタンスを作成。
リポジトリの作り方をミスって作り直したりしてて30分ぐらいロス。立ち上がりに時間がかかる。
午後一でアプリを読んだ結果を共有
- 最終ログイン時間とログイン失敗数は、usersテーブルに書いておけばlogin_logを舐める必要はない
- banned_ipはip管理用のテーブルを追加すればよさそう。(これは最後まで実装間に合わず)
- 最終的には使わない予定だけど、login_logを舐めるのがヒドいので、とりあえずINDEX貼る
CREATE INDEX id_idx_1 ON login_log (ip, id); CREATE INDEX id_idx_2 ON login_log (user_id, id);
-> これだけで3000 -> 10000〜までスコアアップ
- login_logも初期データがあって、最終ログイン時刻とログイン失敗回数はそのデータを反映する必要がありそう。
- @hisayoshに、awkワンライナーで最終ログイン時刻一覧を作ってもらって、最終ログイン時刻だけ反映するSQLを作成
- usersテーブルに最終ログイン時刻とIPを追加して、ログイン時にアップデートするよう変更。
- 最終ログイン時刻と最終ログインIPの仕様を誤解して、手間取る。
- ここまでの改修で20000を超えるようになったが、ポート枯渇などのエラーが出るので、カーネルパラメータを変更し、Nginxとgunicorn間の通信をUnixドメインソケットに変更。
- このタイミングでMySQLを5.6に変更。skip-innodb-doublewrite、innodb_flush_method = O_DIRECT_NO_FSYNC までなら通常の永続化は保たれてセーフだと踏んで設定。これでちょっとスコアアップ。
- ただ、最終提出AMIへの反映が漏れていたことが、あとで発覚。
- 続いて、ログイン失敗回数をusersテーブルに書き込むようアプリを改修。
- @hisayoshに、awkワンライナーでユーザ・IP別のログイン失敗回数一覧を作ってもらう。
- ただ時間が迫ってきているのに焦って、ログイン失敗書き込みが漏れてFail。泥罠的な修正を加えたため、バグを埋め込んでしまい手間取る。
- ベンチマークはFailなしで走るようになったが、初期データの反映ができていないため、レポートで落ちる。。。
- 結局、安定した時点までのアプリでベンチマークが通ることを確認して時間終了。
以上。
こうしてまとめて見てみると、大したことができてなくてつらい(´;ω;`)
大したことないアプリの改修で、舞台に飲まれてバグを埋め込んで時間を使いすぎました。。。
去年の本戦でも感じましたが、こういった時にすぐに解決策が出てこなかったり、コードを修正するのに手間取ったりするのは、普段からの修行不足。
もう予選も終わり、予選用のリポジトリも公開設定に変更したので、恥ずかしながら、使ったリポジトリのURLを貼っておきます。華々しい結果ではありませんが、ISUCONアンチパターンとして見ていただければ。
予選は双六工場こと、僕の自宅から参加したのですが、うちの周りから上野に掛けてIngressのポータルが多いので、予選後は反省Ingress会をやり、上野の「もつ焼き 大統領」でもつとか馬刺しとか食べて解散。
まとめ
振り返って見ると、いろいろ反省点はありますが、判断ミスややりきれなかったところも含めて、今の自分の実力とも思うので、 予選自体にはそんなに悔いはないです。あとはなにかの奇跡が起こって、運良く本戦に引っかかることを祈るのみ。
ISUCONは、すべての参加者が同じ土俵で戦ってベンチマークスコアのみで勝敗が決まる単純さが面白いですね。非常にわかりやすい。なんとなく、幽遊白書の魔界トーナメントを思い出します。やっぱりこういうお祭りがあると、盛り上がるし、エンジニアの実力がこうやって可視化されるのは、間接的にはIT業界全体にとってもいい影響を与えているのではないかと思います。個人的にも、こういう機会があると普段の仕事の時にも気合が入ります。
最後になりますが、運営のみなさま、出題を引き受けてくれたクックパッドのみなさまに感謝を。貴重な機会をいただき、ありがとうございました。毎年規模が拡大し、参加者にもノウハウが溜まってくる中でISUCONを運営するのは、非常に大変だと思いますが、それが続けられているのも、歴代の運営スタップが真剣に取り組んでくれているからだと思います。予選運営お疲れさまでした。
予選通過は厳しい感じではありますが、いずれにせよ本戦が楽しみです。10/6の最終結果発表を楽しみにしつつ、今日はここまでで。
*1:前回も意図したものじゃなくて、チューニングとして意味がありそうなものを順番に試していったら、うまくいくポイントを見つけてしまったというのが実情なんですが
Hadoop Conference Japan 2014 参加メモ(個別セッション③) #hcj2014
Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014 と Hadoop Conference Japan 2014 参加メモ(個別セッション①) #hcj2014 と Hadoop Conference Japan 2014 参加メモ(個別セッション②) #hcj2014 の続きです。
メモはここまで。
並列SQLエンジンPresto - 大規模データセットを高速にグラフ化する方法
- 古橋 貞之(Treasure Data)
会場でPrestoを使っている人はどれぐらいいますか?
- 10人ぐらい
- これは話し甲斐がある
- 10人ぐらい
HDFS上のデータを可視化したい
- Hiveは、可視化には遅すぎる
- ODBC接続が安定しない
- ただし、Hiveは、巨大なJOINなどでは有効
- ODBC接続が安定しない
- Redshift, PostgreSQLは、コストが高いし、スケーラビリティが低かったり
- 中間データベースを使うと、余計な手間がかかる
- Hiveは、可視化には遅すぎる
Prestoを使うと解決可能
- PrestoはHiveにもMySQL上にあるデータにもクエリを投げられる
- Prestoをハブとして解析プラットフォームを作れる
全体アーキテクチャ
Connector
- Hive
- Cassandra
- MySQL(beta)
BI tools needs
Prestgres
- PostgreSQL protocol gateway
- PostgreSQLのODBC/JDBCで接続できる
PostgreSQL に見えるんだけど、裏ではPrestoが動く
- pgpool-Ⅱを改造してクエリを書き換える
- 書き換えたクエリがPostgreSQLの中でさらに各サービスへのクエリに変換される
Tableau/ChartIOからクエリをかけられる
- PostgreSQL protocol gateway
Prestoの実行モデル
Monitoring
Laad map
- Huge JOIN and Group by
- Task revovery
- Create View
- Plugin repository
- Native store
情報源
QA
- 想定質問としてあるのが、Impalaと較べてどうなのか
- 確かにImpalaと比べると遅い
- アグリゲーションの最適化が図られているので、だんだん早くなっている。開発スピードが早い。
- impalaよりも、リソース管理がしっかりしており、メトリクスが取りやすい。運用が考慮されている。
- 拡張性が高く、開発がオープン。
- プルリクエストが2,3週間でマージされる
- 確かにImpalaと比べると遅い
- 想定質問としてあるのが、Impalaと較べてどうなのか
内容のメモは以上です。
Hadoop Conference Japan 2014 参加メモ(個別セッション②) #hcj2014
Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014 と Hadoop Conference Japan 2014 参加メモ(個別セッション①) #hcj2014 の続きです。
長くなったので、最後のセッションはさらに分割します。
A Deeper Understanding of Spark Internals
- Patrick Wendell (Databricks)
Agenda
How spark runs, focus on performance
Major core components
- Excecution model
- The suffule
- Caching <- not cover in this session
Scala example
最初の文字の出現頻度を数える
sc.textFile("hdfs://names") .map(name =x> (name.charAt(0), name)) .groupByKey() .mapValues(names => names.toSet.size) .collect()
Excecution model
Create DAG/RDDs
- HadoopRDD
- map()
- groupby()
- mapValues()
- collect()
- HadoopRDD
Create execution plan
- pipeline as much as possible
- Split into "stages" based on need to reorganize data
Schedule tasks
- split each stage into tasks
- schedule tasks
The shuffle
- Redistribution data
- Pull-based
write intermediate file to disk
- network bound
各パーティションごとにHash mapを構築する
- 一つのキーと値のペアはメモリ上に収まる必要がある
What went wrong?
- Too few partition to get good
- Large per key groupby()
shipped data accross the cluster
Ensure enough partitions
- Minimize memory
- minimize shuffled
- Know the standard library
too few partitions/too many partitions
- reasonable number of partitions
Fix the problem
.repartition(6) .distinct()
Low level performance
QA
Does spark support JOIN?
- yes
Hive, Shark or SparkSQL
- SparkSQLに統合しようとしている
- Sharkは新しいプロジェクトでは使うな
- SparkSQLに統合しようとしている
LT
LTを見に行きましたが、こちらのメモはカオスなので、一旦割愛で。
Evolution of Impala - Hadoop 上の高速SQLエンジン、最新情報
- 嶋内 翔(Cloudera)
- 今日はこのために来たと行ってもいい
Impalaのサービス
impalad
- クエリを実行する
- どのデーモンもクエリを受け付けられる。
- 受け付けたノードがコーディネータ
statestore
- ネームサービス
- impaladの簡単な死活監視のみ
- このサービス自体は死んでいても動作はする
catalogd
- メタデータ管理
- あとで詳細
実行計画
- シングルノードプランの作成
- プランフラグメントに分割
インメモリの実行
メタデータ管理
HBase連携
- 1行インサート可能
- 高速にインクリメントするカウンタをHBaseに持つ等のユースケースが可能
リソース管理
Llama
- 低レイテンシ用のアプリケーションマスタ
- YARNのスケジューリングを細かくするためのサービス
- YARNのリソース配分をキャッシュ
- 1.4でプロダクションレディ
- 低レイテンシ用のアプリケーションマスタ
Sentry
- データベース、テーブル、ビュー、列、行の単位でアクセス制御
- エコシステム全体で利用可能
パフォーマンスと最適化
スケーラビリティ
Impalaはリニアスケーラビリティがある。
HWを倍
- クエリによるがおおよそ倍の性能
- 倍のクラスタで、倍のユーザ
- 同じか良くなる傾向
ロードマップ
- 1.4
下半期に2.0を出す
- LAG
- LEAD
- 相関サブクエリ
- Nested Data(JSONとか)を入れる
Impala本からPDFが無償公開されているので読むと良い
QA
Impalaバージョン同士の比較は?
- バージョンの差異はすぐにはデータがない
UDTFは?
- 望んでいるというのは認識している。プライオリティが高いがまだロードマップに載ってきていない。
Hadoop Conference Japan 2014 参加メモ(個別セッション①) #hcj2014
Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014 の続きです。
続いて、個別セッションの前半。先は長い。。。
個別セッション
BigQuery and the world after MapReduce
Speaker: 佐藤一憲 (Google)
Google I/O で、GoogleはMapReduceを使っていないという話があった
We use Dremel ≒ Google BigQuery(MPP)
- 68B records in ~20 secs
- 120億行フルスキャンで10秒ぐらい
- コスト
- Storage 0.026/GB per manth
- Query: $5/TB
- Column Oriented Storage
HDFSの元となったGoogle File Systemも現在は使っていない
- Colossus
The next generation Google File System
- Tail Latency が低い -> レスポンスが遅いノードに引きずられない
- Colossus
The next generation Google File System
Google BigQuery
Scanning 1 TB in 1 sec takes 5000 disks
処理
- Mixer -> Shards -> Mixer
JOINの方式
- Small JOIN: Broadcast JOIN
- Big JOIN: JOIN EACH, GROUP EACH -> Shuffle
- 608M x 38M records -> 90s
BigQuery streaming
- 1M rows/s を格納可能
- Fluentd Plugin bigquery がこれに対応していて、データを流し込める
Google I/Oで発表された今後実装予定の機能
QA
Fluentdで今後チャンクにIDをつけるようにする。インターネット経由だと重複は結構ある。Googleへのデータ送信時に、そういう重複排除の仕組みは提供されるか。
- 現状はない。インポートしてもらって、Group BYで重複を排除してもらう等が必要。
- Exactly Onceに関しては、Google I/Oでも質問があって、Dataflowの中ではできている。
BIツールから直でつないで使うのか、スプレッドシートに書きだすのか、どちらの使い方を想定しているか
- 両方ともユースケースがある
大きなデータでクエリが走らないのは?
- おそらくソフト的なクォータ設定で止まっている。
- サポートを購入してもらうと制限を外せる
- Reserved Capacityというメニューがある
クエリの結果の整合性は?
- トランザクションはサポートしていないし、スナップショットとしての整合性も保証していない
Hivemall: Apache Hiveを用いたスケーラブルな機械学習基盤
- Speaker: 油井 誠(産業技術総合研究所)
Hivemallは、Hive上で動くOSSの機械学習ライブラリ
- HiveのUDF、UDTFで実装されており、Hiveに慣れていれば、追加の学習コストが少ない
- 学術研究の結果をいち早く取り込んでいる
既存ツールはプログラムが必要
- すべてのステップがHiveQLで実行可能
- add jar
- source のみで実行可能
- すべてのステップがHiveQLで実行可能
特徴数の削減をサポートしている
- 学習時やテスト時に予測モデルをメモリに収める必要がない。
EMRに自動構築するBootstrapを提供している
最新のオンライン学習アルゴリズムをサポート
- CW、SCW、AROWをサポート
- 学習の収束が高速
- 10イテレーション→2, 3イテレーション
オンライン学習で精度がよい
- confidence weighted
- 重みと確信度を更新する
- 確信度が十分な重みについては、小さな更新。学習初期は大きな更新。
- confidence weighted
UDAF(集約関数)での機会学習
-
- Sparkは担当領域を各ノードでキャッシュするので今後のバージョンで高速化する可能性がある
- SparkのMLlib はサンプリングを利用したMini-batch勾配降下法
Hivemall
- amplify UDTFでデータを増幅してShuffle
- rand_amplify UDTFでデータを増幅してMap Only Shuffle
Apache incubator化の打診がある。Hortonworksから打診を受けている。
QA
Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014
久々にブログを更新しようと思ったら、この数カ月で記事らしい記事は「一人遊園地」しか書いていないことに軽い絶望を覚えたせちろーです。
今日は、Hadoop Conference Japan 2014に参加してきたので、その時に取ったメモを整理してアップ。長くなるので、まずはキーノートから。間違いがあってもご容赦ください。
当日の資料は、以下のページにアップされると思うので、詳しい情報は以下を見てください。
http://www.eventbrite.com/e/hadoop-conference-japan-2014-tickets-12016613013
それぞれ別の立場から話しているのに、Hadoopの用途が大量データの保存と単純な集計から、汎用的な分散処理基盤かつMPPまで包含するような方向で進化しているという観点が共通しているところが面白いですね。
キーノート
開会挨拶
- 参加登録者
- 1296名 -> 最終的には1299名
- 約65%が初めて参加する人
データ
Hadoopのこれまで
だんだんYARNが中心に座ってきている
- MRの経験をもとに複数の分散処理エンジンを使い分ける時代に
『The Future of Data』
未来は予測できないが、いくつかの事実が真実を予測
『The Future of Spark』
- Speaker: Patrick Wendell (Apache Spark主要開発者, Databricks)
今日のスライドは、自分で日本語に翻訳した
Spark開発者の一週間
- 500 Patch
- 200 update issue
- 140 Mail thread
- ...
Spark開発目標
- Data scientist, engineerの能力拡張
- CleanなAPI
- 多様な環境に適用
- 強力な標準ライブラリ
API互換性を維持
Spark Stack
- Spark SQL
- MLlib
- Graph X
- Spark Streaming
Sparkの未来は「ライブラリ」
- パッケージ化してどこでも使えるように
Spark SQL
DatabricksではクラウドでSparkを提供している
『Hadoopエコシステムの変遷と、見えてきた使いどころ』
- Speaker: 太田 一樹 (Treasure Data CTO)
- Hadoopの本質的な価値とは
- Collect any types of Data
- Store any types of Data Economically
- Faster use of Data
- Better use of Data
ここまで使うことでHadoopの価値が出る
Collect any types of Data
- Fluentd
- Apache Flume
- Kafka
- Sqoop
Store any types of Data Economically
- どんなタイプのデータも格納可能
- ファイルフォーマットに注目が集まっている
- どんなタイプのデータも格納可能
Faster use of Data
Better use of Data
- Impala, Presto, Drill
- Mahout, Hivemall
データベースの進化
スキーマ管理がもたらす問題
- 一部のレポートしか作れない
- データの整合性はとれるが、出てくるころには使えない
現在のトレンド
今後、Hadoopは構造化データとの境界線に突入
- HadoopだけでMPPができるように
- トレンドを読みながら技術を利用すべき
キーノートのメモはここまで。
溜まってきた大量の名刺やシャッツキステのポイントカードをしまうのにちょうどいい道具を調べた
最近、名刺やらシャッツキステのポイントカードが貯まってきて、カード状のものを保存するのに使えそうな道具を調べたので、その時の内容の備忘録を書いてみました。*1
自分で探せていない範囲がまだありそうなので、この用途でもっといいものがあれば、教えていただけるとありがたいです。
調べるにあたっての前提
以前は、名刺はきちんと名刺ファイルにファイリングしていました。しかし最近は、ものぐさでファイリングしなくなってしまっていて、その管理方法も限界に…。また、電子化しておいて、実物は廃棄してしまうという方法もあると思うのですが、収集癖があるから現物を捨てるのは忍びないので、それも今回は除外。
上記の前提なので、今回は入れるのに手間がかからない箱状のものをターゲットとしました。
どうやって見つけるか
箱状のものを使うと決めたものの、最初にカード状のものをしまう箱をどういう単語で検索すべきかという問題に引っかかりました。いろいろ試行錯誤して検索してみた結果は以下の通り。
- カードホルダー → ハズレ
- 主に社員証をぶら下げるものや財布上のカード入れが引っかかる。
- カードケース → ハズレ
- 主に財布上のカード入れが引っかかる
- カードボックス → 当たり!
- 主に名刺を1000枚単位で収納できる箱やカードゲーム用カードを入れる箱が引っかかる
- 「ネームカードボックス」とすると、名刺をしまう箱に絞り込める。
- 名刺箱、名刺ケース → 当たり!
- 名刺を買った時に入っているような箱が引っかかる。
- ネームカードケース → 微妙
- 主に社員証をぶら下げるものが引っかかる。ただし、あとで取り上げる今回買った製品がたまたま「ネームカードケース」という製品名だったため、それだけ例外的に引っかかった。
「名刺箱」というのは、見つけてしまえば当たり前の検索ワードなのですが、当初は「カードケース」で検索していたので、なかなか見つけられずに苦労しました。。。
500枚以上のカードを入れるのに使えるもの
今回探したものの中で、500枚以上のカードがある場合に使えると思ったのは「カードボックス」系のものです。このジャンルのものは、今回初めて知りました。探してみるとあるもんなんですねー
自分で買ったのは以下の「ネームカードケース」。選んだ決め手は、下の箱の高さが名刺の縦幅よりも低く、名刺が取り出しやすい点。この製品はフタがパカっと完全に外れるタイプなので、フタに蝶番がついている方がお好みであれば、そちらもよいかも。
また、今回はファイルはなしということで除外しましたが、カードボックスの類似製品として、このジャンルだと下の商品のような円形に名刺をパタパタ入れていくものも見つけました。
「ローロデックス」という製品なんですね。どこかで見た気がしますが、名前を知るのは初めて。名前を知らないと全然見つけられない。。。
数百枚程度のカードを入れるのに使えるもの
数百枚程度のカードを入れる場合は、今見つけられているものの中では「名刺箱」が良さそうという結論です。名刺を買った時の箱が残っていれば、それを使うのが一番リーズナブルですが、単体で買うこともできました。
ただ、安い名刺箱はネットでは5個単位、10個単位ものが多くて、1個だけ買う方法がなさそうなのがネック。余った分は、小物の整理にも使えるので、まとめて買っても使うところはあるように思いますが。
透明なものがいいか、中は見えない方がいいかは好みの問題ですが、以下のようなものがありました。*2
3240円以上で送料無料!(沖縄県をのぞく)幅57x奥行93x高20mm名刺が100枚入るサイズです【HEIKO/... |
高級感が欲しい場合
今回自分では買っていませんが、「名刺箱」で調べてみると、凝ったものも見つかりました。千代紙のものは、値段も手頃なので個人名刺入れとかによいかも。ほかにも、漆器で1万円超えみたいなものも見つかりましたが、さすがに使う機会なさそう…。
【ホームステイのお土産】【海外出張の手土産】【和柄】【外国人に喜ばれる】【日本のおみやげ... |
木製漆塗りの縁起物の名刺箱(名刺ケース) ラッキーアイテム ビジネスギフト、父の日ギフト、就... |
以上、どこにニーズがあるかわかりませんが、調査メモでした。
今日はこの辺で。
一人遊園地に行ってみた
今日は、花やしきに行ってきました。行った理由は、花やしきのローラーコースターに乗ってみたかったから。
全然下調べせずにいったので、花やしきのローラーコースターがまだやっているか不安でしたが、行ってみたところ、まだまだ現役で稼働していました!
なんと去年還暦! そして、還暦の人は無料で乗り放題!!
楽しい!!! ✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌.
ただ、周りはカップルか子供連ればっかりで、一人で行くとその人の心が試されます。人の迷惑にならない限り、どんなところでも行きたかったら行くべきだとは思いますが、周りがキャッキャウフフしている中に一人でいると精神が徐々に蝕まれていくので、基本的には一人で遊園地に行くのはおすすめできませんね。
ちなみに、一時期Twitterで回っていたぼっち検定では、一人遊園地は上から2つ目のレベルになっています。ただ、神レベルのラブホテルは、旅行で使えば割と簡単に達成できるし、千葉のネズミの国はパスポート持ってソロで行ってる人が結構いるので、上位の方が割と簡単に達成できるような気もします。
【ぼっち検定】 初級 一人で牛丼 5級 一人でラーメン 3級 一人でファミレス 1級 一人で居酒屋 初段 一人で温泉 ニ段 一人で回転寿司 三段 一人で海水浴 五段 一人で焼肉 名人 一人で公園の手漕ぎボート 独聖 一人で遊園地 神 一人でラブホテル
今日はこんなところで。