TL;DR

1. When Kubernetes nodes exceed 1000, node exporters deployed as DaemonSets on each node also increase.
2. When Prometheus Operator performs Service discovery with Service monitor, it references the service’s endpoints by default.
3. Kubernetes Endpoints objects have a default limit of 1000 IPs.
4. Only 1000 Prometheus scrape targets are maintained.
5. Prometheus should use endpointslices instead of Kubernetes endpoints for Service discovery.

As Kubernetes clusters grow and the number of nodes exceeds 1000, various challenges arise. One particularly important issue from a monitoring perspective is Prometheus Service Discovery.

For node-exporter, cadvisor, kubelet metrics, etc. deployed as DaemonSets on each node, the number of endpoints increases with the node count. For example:

• node-exporter: 1000 nodes = 1000 targets
• kubelet metrics: 1000 nodes = 1000 targets
• cadvisor: 1000 nodes = 1000 targets

The problem lies in the limitations of Kubernetes’ default Endpoints object. A single Endpoints object can only store up to 1000 IP addresses. When nodes exceed 1000, nodes from 1001 onwards are not included in the Endpoints, resulting in Prometheus being unable to scrape them.

# kubectl get endpoints node-exporter -n monitoring -o yaml
apiVersion: v1
kind: Endpoints
metadata:
  name: node-exporter
  namespace: monitoring
subsets:
  - addresses:
      - ip: 10.0.1.1
      - ip: 10.0.1.2
      # ... up to 1000 only
      - ip: 10.0.4.232
    ports:
      - port: 9100
        protocol: TCP

In this situation, if metrics from some nodes are not collected, monitoring blind spots occur and alarms may not work properly.

Endpoints and EndpointSlices

Kubernetes Endpoints objects store IP addresses of Pods connected to Services. However, there are several limitations:

1. Size limitation: A single Endpoints object can store a maximum of 1000 IPs
2. Performance issues: Large Endpoints objects burden etcd and the API server
3. Update inefficiency: The entire Endpoints object is updated even when a single Pod changes

EndpointSlices, introduced from Kubernetes 1.16, were designed to solve these problems:

1. Distributed storage: Stored as multiple small objects (100 endpoints per slice by default)
2. Efficient updates: Only modified slices are updated
3. Scalability: Can scale without node count limitations

# kubectl get endpointslices -n monitoring -l kubernetes.io/service-name=node-exporter
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: node-exporter-abc123
  namespace: monitoring
  labels:
    kubernetes.io/service-name: node-exporter
addressType: IPv4
endpoints:
  - addresses:
      - 10.0.1.1
    conditions:
      ready: true
  - addresses:
      - 10.0.1.2
    conditions:
      ready: true
# ... up to 100
ports:
  - port: 9100
    protocol: TCP
---
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: node-exporter-def456
  namespace: monitoring
  labels:
    kubernetes.io/service-name: node-exporter
# ... next 100

Comparison Table

Endpoints API Deprecation

Starting from Kubernetes 1.33, the Endpoints API is officially deprecated, and the API server returns warnings to users who read or write Endpoints resources without using EndpointSlices. For more details, see the official Kubernetes blog.

Prometheus Operator’s serviceDiscoveryRole

When using Prometheus Operator, scrape targets are defined through the ServiceMonitor CRD. ServiceMonitor discovers targets by referencing Kubernetes Service Endpoints by default.

Prometheus Operator v0.81.0 Spec: Prometheus

Starting from Prometheus Operator v0.50.0, the serviceDiscoveryRole field was introduced to allow selecting the Service Discovery method:

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: kube-prometheus
  namespace: monitoring
spec:
  serviceDiscoveryRole: EndpointSlice # default: Endpoints
  serviceMonitorSelector:
    matchLabels:
      team: platform

Possible values:

• Endpoints: Use traditional Endpoints objects (default)
• EndpointSlice: Use EndpointSlices

Considerations When Changing Settings

1. Check Kubernetes version: EndpointSlices are available in k8s 1.16+, GA in 1.21+
2. Update RBAC permissions: Need to add permissions for Prometheus to read EndpointSlices

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
  - apiGroups: ["discovery.k8s.io"]
    resources:
      - endpointslices
    verbs: ["get", "list", "watch"]

3. Gradual migration: Validate in test environment first before applying to production

Prometheus Operator and Kubelet Endpoints

Kubelet metrics work differently from the typical Service/Endpoints pattern. Kubelet is a system component running on each node that must be accessed directly without a Service object.

Prometheus Operator automatically creates and manages Endpoints objects for collecting kubelet metrics by default:

apiVersion: v1
kind: Endpoints
metadata:
  name: kubelet
  namespace: kube-system
  labels:
    app.kubernetes.io/managed-by: prometheus-operator # Managed by Operator
    app.kubernetes.io/name: kubelet
    k8s-app: kubelet
subsets:
  - addresses:
      - ip: 10.0.1.1 # node1
      - ip: 10.0.1.2 # node2
    # ... can store up to 1000 only
    ports:
      - name: https-metrics
        port: 10250

The app.kubernetes.io/managed-by: prometheus-operator label indicates that these Endpoints are automatically managed by Prometheus Operator.

Issues

When Prometheus’s serviceDiscoveryRole is changed to EndpointSlice, kubelet also uses EndpointSlice. However, Kubernetes EndpointSlice mirroring has a 1000 limit:

• EndpointSlice mirroring controller mirrors (by default) a maximum of 1000 endpoints (reference)
• With more than 1000 nodes, EndpointSlice cannot scrape all kubelets

Solutions

1. Safe Migration Strategy (Recommended)

This is the safe migration method suggested in Prometheus Operator GitHub issue #7678:

Step 1: Configure to manage both objects

# Prometheus Operator Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-operator
  namespace: monitoring
spec:
  template:
    spec:
      containers:
        - name: prometheus-operator
          args:
            - --kubelet-endpoints=true # Continue managing Endpoints
            - --kubelet-endpointslice=true # Also manage EndpointSlice

Step 2: Verify EndpointSlice object creation

# Verify that EndpointSlice was created successfully
kubectl get endpointslices -n kube-system -l kubernetes.io/service-name=kubelet

# Check created EndpointSlice
kubectl get endpointslice kubelet-8jkql -n kube-system -o yaml

The created EndpointSlice includes the following labels:

metadata:
  labels:
    app.kubernetes.io/managed-by: prometheus-operator
    endpointslice.kubernetes.io/managed-by: prometheus-operator # Directly managed by Operator
    kubernetes.io/service-name: kubelet

Step 3: Configure Prometheus to use EndpointSlice

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: kube-prometheus
spec:
  serviceDiscoveryRole: EndpointSlice # Use EndpointSlice

Step 4: Disable Endpoints after confirming normal operation

# Disable Endpoints management when everything works normally
args:
  - --kubelet-endpoints=false # Stop creating Endpoints
  - --kubelet-endpointslice=true # Manage only EndpointSlice

2. Preventing EndpointSlice Mirroring

Endpoints managed by Prometheus Operator have special labels added:

apiVersion: v1
kind: Endpoints
metadata:
  labels:
    app.kubernetes.io/managed-by: prometheus-operator
    endpointslice.kubernetes.io/skip-mirror: "true" # Prevent mirroring

The endpointslice.kubernetes.io/skip-mirror: "true" label prevents Kubernetes’s EndpointSlice mirroring controller from automatically mirroring these Endpoints to EndpointSlice. This is because Prometheus Operator directly manages the EndpointSlice.

3. Before and After Migration Comparison

Before migration (managed by Mirroring Controller):

kind: EndpointSlice
metadata:
  labels:
    endpointslice.kubernetes.io/managed-by: endpointslicemirroring-controller.k8s.io

After migration (directly managed by Prometheus Operator):

kind: EndpointSlice
metadata:
  labels:
    app.kubernetes.io/managed-by: prometheus-operator
    endpointslice.kubernetes.io/managed-by: prometheus-operator # Directly managed by Operator

Conclusion

When Kubernetes clusters grow beyond 1000 nodes, monitoring systems must be designed to scale accordingly. By utilizing EndpointSlices, stable metric collection is possible without node count limitations. Migration can be easily accomplished through Prometheus Operator’s serviceDiscoveryRole setting, and for kubelet metrics, the transition can be made using both --kubelet-endpoints and --kubelet-endpointslice flags together.

I particularly think that Kubernetes resources are not suitable for text templating like HTML. These manifest files represent various APIs supported by Kubernetes and are essentially structured data. And I thought that the most effective tool for processing structured data is a programming language.

Given that Kubernetes is essentially an API, and all operations performed within a Kubernetes cluster (such as creating Pods or monitoring services) ultimately involve interaction with that API. The Kubernetes API server automatically generates and provides complete OpenAPI specifications for all resources and operations.

So with the help of (recently trendy) vibe coding, I wrote kamut in Rust.

The basic structure is simple. By writing deploy.kamut.yaml as follows, you can generate deploy.yaml with the kamut CLI.

deploy.kamut.yaml

kind: Deployment
name: my-app
image: nginx:latest
replicas: 3
env:
  APP_ENV: production
  DEBUG: "false"
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 200m
    memory: 256Mi

deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: nginx:latest
        env:
        - name: APP_ENV
          value: production
        - name: DEBUG
          value: "false"
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 200m
            memory: 256Mi

Because it uses definitions for structured data (structs generated based on OpenAPI spec), validation of structural flaws is possible during manifest generation. Actually, generation becomes impossible if there are structural issues.

In Rust, there are also libraries for definitions of resource types in the Kubernetes client API that are automatically generated from the Kubernetes OpenAPI specification.

• metio/kube-custom-resources-rs: Kubernetes Custom Resource Bindings for Rust
• Arnavion/k8s-openapi: Rust definitions of the resource types in the Kubernetes client API

Since Kamut is a toy project for learning Rust, if you’re interested in this approach and want to try it out, I’d recommend yoke. ;-)

What is GreptimeDB?

GreptimeDB is an open-source cloud-native time series database that integrates metrics, logs, and events.

GreptimeDB as Prometheus Long-term Storage

Key features include:

Unified Data Model: It can handle metrics, logs, and events (possibly traces too?) in a single database. GreptimeDB’s data model treats all time series as events with timestamps and context, allowing management under a single model. GreptimeDB supports SQL, enabling queries that can retrieve both metrics and logs in a single query.

Support for Various Collection Protocols: Supports various observability data including Prometheus, InfluxDB, MySQL, OpenTSDB, etc.

Parquet-based Column Storage: Efficient structure for high cardinality data

Computing and Storage Separation Based on Cloud Object Storage: Independent scalability of each resource

Various Indexing Strategies: In Prometheus, all labels are indexed. GreptimeDB allows you to set indexing for specific labels (tags) only. (Both Scanning+Pruning and Indexing can be used)

Architecture

• Metasrv: Metasrv manages database and table information. This includes how data is distributed within the cluster and how collection and query requests are routed. (Requires etcd by default, but also supports pgsql and mysql).
• Frontend: Supports various collection/query protocols and forwards requests to the Datanode according to the direction of Metasrv for collection and queries.
• Datanode: Manages table regions in the cluster. It receives read and write requests forwarded from the Frontend, processes the data, and returns results.

Cortex or Mimir manages only the ingester information in etcd or consul as a hashring (though they use gossip protocol these days). Compared to this, GreptimeDB’s metasrv manages not only the status of each component but also the table partitioning information, making it contain more metadata and requiring greater stability.

Installation

GreptimeDB supports GreptimeTeam/greptimedb-operator: Run GreptimeDB on Kubernetes. to support operation on Kubernetes.

It also supports GreptimeTeam/helm-charts: Helm charts for deploy GreptimeDB., making configuration easy.

Prometheus and GreptimeDB’s Data Model

GreptimeDB’s data model is composed of Tables with Tags, Fields, and Timestamps. It can be viewed as a multi-value data model similar to InfluxDB’s data model, and it automatically groups multiple Prometheus metrics into (physical) tables.

While Prometheus labels are all indexed, GreptimeDB’s data model explicitly distinguishes between tags and fields. Low-cardinality labels can be configured as tags that are indexed (not all tags need to be indexed). High-cardinality data can be configured as fields (while Prometheus is fixed with labels and value, schema configuration in GreptimeDB can be more flexible). And by grouping into tables, storage and query efficiency can be achieved by eliminating duplicate fields.

GreptimeDB’s frontend supports Prometheus remote write and Prometheus HTTP API (which can be used as a Grafana data source).

remote_write:
  - url: http://localhost:4000/v1/prometheus/write?db=public
remote_read:
  - url: http://localhost:4000/v1/prometheus/read?db=public

While Cortex or Thanos separates the ingest component and query component, GreptimeDB’s frontend handles both. Since these two workloads are different, it would be appropriate to divide the frontend into read-only and write-only configurations.

Table Region and Datanode

I have Prometheus configured as a collector for each Kubernetes cluster and forward it to long-term storage via Prometheus remote write (collecting all metrics in Prometheus). In this structure, when forwarding to GreptimeDB as long-term storage, I discovered that metrics weren’t distributed across multiple datanodes but rather routed to a single datanode.

From my experience with Cortex/Thanos, I thought metrics should be distributed across multiple ingesters (datanodes) (but I was wrong). The reason metrics are collected into a single datanode is (to get to the conclusion) there is only one physical table for metrics. Therefore, only one datanode provides all logical regions of that table. So you can find multiple regions in the same datanode. Metric Engine | GreptimeDB Documentation | Unified Time-Series Database

If you want to distribute workload across multiple datanodes, you need to partition the table. However, it seemed there was no approach yet to evenly partition by hashing job labels.

And because metrics are collected into a single datanode, if that node restarts or is in poor condition, it will fail to read all metrics. There should be datanodes (follower peers) that can distribute reads other than the datanode (leader peer) responsible for writes, but this isn’t available yet and is planned to be activated in the enterprise edition. Tracking Issues / Follower regions · Issue #5739 · GreptimeTeam/greptimedb

…

Conclusion

Looking at GreptimeDB so far, I learned several interesting points in the process. To list them somewhat randomly:

• The distinction between write and read layers is necessary.
• The distinction between processing recent data and long-term data is necessary.
• When Prometheus TSDB labels have very high cardinality, storing and searching the inverted index is costly. On the other hand, the scanning+pruning approach commonly used in analytical databases can effectively handle such scenarios, and a hybrid approach might be more effective.

Each solution is the root of the next problem – Gerald M. Weinberg

I’ve been using Jsonnet for several years, and I think it would be good to summarize my experiences so far.

The good

The best thing about Jsonnet is that it’s a superset of JSON. As a data templating language for generating JSON, it provides many features of programming languages (variables, functions, arithmetic operations, conditionals). Since it can generate JSON, it can also generate YAML, which is why I use it with tanka to create Kubernetes manifests.

In my opinion, the biggest drawback of Helm is its simple Go/template-based templating. I believe the following template work exemplifies the problems that arise in templating languages that fundamentally don’t understand their output:

metadata:
  labels:
    {{- include "ingress-nginx.labels" . | nindent 4 }}
    {{- with .Values.controller.labels }}
    {{- toYaml . | nindent 4 }}
    {{- end }}
  annotations: {{ toYaml .Values.controller.annotations | nindent 4 }}
...

If written in Jsonnet, it would look like:

metadata: {
    local labels = import "ingress-nginx-labels.jsonnet",
    labels: labels + $.values.controller.labels,
    annotations: $.values.controller.annotations,
}

Above, $ refers to the top-level object at the time of evaluation. In other words, it points to the outermost object when the Jsonnet file is evaluated. In contrast, self refers to the object currently being defined.

Helm treats templates as strings without understanding the target. Jsonnet templates JSON by adding various language features.

{
  a: 1,
  b: self.a + 1,  // self.a references 1, result is 2
  nested: {
    x: 10,
    y: self.x + 5,  // self.x references 10, result is 15
    z: $.a + 5      // $.a references the top-level object's a(1), result is 6
  }
}

Helm’s “oil and water strategy” is similar to inserting Smalltalk syntax into C like in Objective-C, and is widely used when templating HTML in web servers.

However, this strategy feels like wiring your brain in two layers. Having a template language that understands what it’s templating is (in my personal opinion) a good approach, not a bad one - especially when the target is defined in YAML or JSON, like with Kubernetes.

The bad

Jsonnet’s Merging feature allows you to modify an object from multiple files.

local baseConfig = {
  name: "app",
  resources: {
    memory: "1Gi",
    cpu: "100m"
  }
};

local overrides = {
  resources: {
    memory: "2Gi"
  },
  replicas: 3
};

// Result will have merged fields
baseConfig + overrides

The result is:

{
  "name": "app",
  "resources": {
    "memory": "2Gi"
  },
  "replicas": 3
}

The interesting point here is that the contents of resources have been replaced with the contents from overrides. If you want to merge the contents of resources from baseConfig with those from overrides, you would do:

local overrides = {
  resources+: {
    memory: "2Gi"
  },
  replicas: 3
};

By using resources+:, the contents of resources are merged rather than replaced. This feature effectively makes all objects open.

Helm is a combination of templates + values. While this makes it difficult to use values in ways that deviate from the intent of the templates, it also has the advantage of formalizing usage to reduce structural complexity. kube-prometheus/jsonnet/kube-prometheus adopts this structural characteristic (advantage) of helm with its components and values structure.

However, having all objects always open is both an advantage and a disadvantage. The kube-prometheus structure is just a kind of pattern that cannot be enforced. Things can always become complex.

The meh

In my personal experience, debugging Jsonnet is always difficult. You can output intermediate objects with std.trace(), but that’s not enough. Although this is a problem derived from Jsonnet’s power, I think there should be more linguistic constraints to prevent users from misusing Jsonnet. This thought leads me to consider CUE. For large and complex manifests, CUE could provide more stability. But that might mean losing the advantages that come with Jsonnet’s power. (In some ways, the advantage is also the disadvantage.)

Conclusion

While Jsonnet’s charm is good, its advantages seem to fade in complex structures. Since Kubernetes manifests are essentially requests to the Kubernetes API, I sometimes wonder if the answer might be to generate them using regular programming languages, like bwplotka/mimic: mimic: Define your Deployments, Infrastructure and Configuration as a Go Code 🚀.

Cortex, started by Tom Wilkie and Julius Volz (Prometheus’ co-founder) in 2016, has several interesting architectural features. As one of Prometheus’ long-term storage solutions, Cortex has been referenced by many time-series based storage architectures (tracing, log) since then (especially in the Grafana stack).

Prometheus

Prometheus can be considered a kind of monolithic architecture.

Because everything is together, technical problems (that arise in microservices) do not occur, but each component cannot be scaled individually according to its specific purpose. In some ways, Cortex can be seen as a microservice version of Prometheus.

Ingester & Distributor

In Cortex, the ingester is the most important component. It’s the component that collects time series through Prometheus remote write, and since Prometheus TSDB creates blocks every 2 hours, it needs to respond to querier’s query requests for metrics from the last 2 hours. Since it holds the TSDB’s Head Block in memory, it’s fast for recent metric requests. Due to the nature of time series usage, recent data usage is an important pattern (e.g., for alerts).

Data replication is important for reliability in any distributed system design. The Distributor also copies the same data to multiple Ingesters according to the RF (Replication Factor). It might seem like a waste of resources, but if a specific ingester fails, another ingester with replicated data can respond. From a query performance perspective, queries can be distributed based on duplicated data.

Ingesters don’t need to know much about each other. This advantage creates another disadvantage: duplicated data is uploaded to S3. Later, the compactor cleans up this duplicated data (similar to LSM Tree).

What happens if an ingester restarts before uploading a block (before 2 hours)? The ingester must upload the data it has so far to S3 during shutdown.

Store gateway & Compactor

Looking at the TSDB structure, a database called a block is created hourly, and data is stored as index and chunks within the block. The ingester stores these TSDB blocks in an object store (S3), and the store gateway finds and delivers the necessary TSDB in response to querier requests. Since the store gateway needs to retrieve large amounts of data from the slow object store, it uses caches for the index and chunks, and query performance depends heavily on the cache hit ratio.

The compactor takes blocks that start at 2 hours and gradually creates larger blocks with increased time spans. Since there are duplicate indexes across different time periods, compaction also has a (positive) impact on query performance.

Some notes about Cortex architecture

In my personal opinion, Cortex architecture seems like a kind of distributed and coordination-(half)free architecture. If you look at RDB sharding solutions, they have a lot of meta information needed for coordination between each component, but Cortex only maintains simple status and connection information for ingesters in metastores like Consul. They don’t hold much information about each other and allow duplicated data and fan out requests redundantly, but because they don’t know much about each other, they can act simply.

• Control plane upgrade (+ etcd)
• Node upgrade

Particularly when using cloud-managed Kubernetes like EKS, since AWS manages the control plane, you’ll mostly handle node upgrades directly (if you’re not using managed nodegroups).

When you upgrade the control plane, you’ll have nodes with different versions of kubelet as shown in the diagram below:

For clusters that are not large-scale, you would typically create a new node group of the same size as the current one and relocate pods from the previous node group to the newly created node group (temporarily maintaining twice the number of nodes).

In this case, you need an efficient way to relocate all applications. But what exactly is relocation? Despite its name, is it any different from a regular deployment?

Approaching exceptional situations as normal ones helps prevent many problems. In reality, although we call it relocation, it’s not much different from a regular deployment except that the purpose is relocation.

However, since it’s inconvenient to relocate (redeploy, restart) hundreds of applications at once, I wrote a simple CLI for a kind of simple automation.

anarcher/kroller

$ kroller -h
USAGE
  kroller <subcommand>

SUBCOMMANDS
  restart  restart all rollout resources
  drain    drain node
  show     show details of nodes or resources
  version  show version of kroller

FLAGS
  -kubeconfig ...  kubeconfig file
  -v false         log verbose output

Looking at the list of subcommands, first there’s a command called restart.

$ kroller restart -h
USAGE
  restart all rollout resources (deployment,statefulset)

FLAGS
  -config ...         config file (optional)
  -kubeconfig ...     kubeconfig file
  -target ...         only use the specified objects (Format: <namespace>/<type>/<name>)
  -v false            log verbose output

The most interesting flag is -target.

  -target ...         only use the specified objects (Format: <namespace>/<type>/<name>)

As a cluster grows over time and includes many Kubernetes objects, you might need to operate on only a subset of them (e.g., apply to only certain applications).

The -target flag provides the ability to limit which objects to restart. (Format: <namespace>/<type>/<name>) Especially since it supports RE2, you can use all kinds of wildcards and other advanced matching features to select Kubernetes objects.

The format and structure of this flag is borrowed from Output filtering | Grafana Tanka.

Next is the -config flag. It’s not common to restart all applications at once; instead, you’d typically perform a phased operation. For example, you might distinguish between service applications and addons (e.g., ingress, etc.) for staged redeployment. In such cases, rather than writing -target each time, you write a config file and run it.

# flux-system.cfg
target flux-system/deployment/.*
v

The config file is simply writing the flags for kroller restart to a file. So not just -target but other flags can be written to the config file as well.

There are also features like kroller show nodes to check nodes and pods.

I created a simple presentation about Prometheus. I uploaded it using sporto/hugo-remark: A theme for using remark.js with hugo, and I found that creating it in markdown rather than PowerPoint allowed me to focus more on the content. (But that doesn’t necessarily mean the content is better.)

| “He who knows one, knows none” - Max Müller

Prometheus is the monitoring system I encountered after Graphite. Graphite is a metric-based monitoring system written in Python. But due to its file-based TSDB characteristics, it’s difficult to solve Series Churn problems when they occur(One file per time series). This problem got worse when cloud environments like AWS were set up, because servers became instances.

While Prometheus isn’t completely free from this problem, it has a fundamentally better structure because it handles data in blocks and chunks. (I believe I heard that Prometheus TSDB v1 had a structure similar to Graphite.)

Graphite performs metric aggregation during collection through carbon relay, but if some metrics that are targets for aggregation arrive late due to network instability, the aggregation results become distorted. (We often described these metric graphs as having “missing teeth”.)

In contrast, Prometheus uses a pull model, and its Recording Rules approach queries metrics collected in the TSDB for aggregation. This makes reliability easier to guarantee. While Graphite can discard raw metrics after aggregation, Prometheus must first store raw metrics in the TSDB to perform aggregation.

In my personal opinion, scraping targets has better manageability than receiving metrics from thousands of servers. (Of course, Service Discovery functionality is necessary for this.)

For REST API development, Design first with writing spec and then generating codes from it is a good approach. goa is a famous tool for this style.

Generate go-swagger spec

The go-swagger has a command that will let you generate a swagger spec document from codes. The command scan all files from current directory or specific file path to sub directories.

To generate a spec:

swagger generate spec command makes swagger.json spec.

// Package rest HTTP API.
//
// Schemes: http
// Host: localhost
// BasePath: /
// Version: 0.0.1
// Consumes:
// - application/json
// Produces:
// - application/json
// swagger:meta
package rest

//go:generate swagger generate spec -m -i ./swagger.yml -o ./static/swagger.json

Operations and struct model mapping

One of reasons why I choose swagger or api documentation generation tool is that parsing source code and using on api spec.

// swagger:operation POST /v1/articles Article create_article
// Create an article resource
//
// ---
// summary: Create article
// parameters:
//  - in: body
//    required: true
//    schema:
//       $ref: "#/definitions/createArticleRequest"
// responses:
// responses:
//  '200':
//   description: successful operation
//   schema:
//    $ref: "#/definitions/Article"
//  '500':
//   description: failed operation (error)
//   schema:
//    $ref: "#/definitions/Error"
//
func createAppHandler(context *gin.Context) {
...

The definitions/Article and definitions/Error are mapping from struct with swagger:model

// swagger:model
type Article struct {
    ID         string    `db:"id" json:"id" yaml:"id"`
    Name       string    `db:"name" json:"name" yaml:"name"`
    CreateTime time.Time `db:"create_time" json:"create_time"`
    UpdateTime time.Time `db:"update_time" json:"update_time"`
}

It is convenient if you have complex request and response payloads.

Embedded static asset(swagger.json) with go-bindata

I want to embedded the swagger-ui and redoc frontend page to my rest api server. go-bindata converts any text or binary file into Go source code.

go:generate go-bindata -prefix "static/" -o static/bindata.go -pkg static static/...

That’s it. the swagger.json is embedded in golang code. With gin framework, you can use it with staticbin.

import  "github.com/olebedev/staticbin"

...

router.Use(staticbin.Static(static.Asset, staticbin.Options{
        Dir: "/static",
}))

Embedded with swagger-ui, you can use swagger-doc’s assets for it.

import (
    swaggerDoc "github.com/utahta/swagger-doc"
    swaggerAsset "github.com/utahta/swagger-doc/assets"
)


...

router.Use(staticbin.Static(swaggerAsset.Asset, staticbin.Options{
        Dir: "/swagger-ui",
}))
router.Any("/redoc", gin.WrapH(swaggerDoc.NewRedocHandler("/static/swagger.json", "redoc")))

I’m not sure this approach is good. I think that better approach exists for it. apiblueprint is simple yaml structure than swagger’s yaml. but I have not found good apiblueprint utils for my taste for golang code generation or spec generation from code.

bumpversion

bumpversion is automation for semantic versioning. Most of my projects have simple config file like below. (.bumpversion.cfg)

[bumpversion]
commit = True
tag = True
current_version = 0.8.4
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)
serialize = 
	{major}.{minor}.{patch}
[bumpversion:file:VERSION]

Before release,I just run like below:

bumpversion minor # or major or patch

This update minor version number in VERSION file. (In this case, 0.8,4 -> 0.9.0) And I configure commit=True and tag=True in .bumpversion.cfg,The bumpversion makes a commit and tag.

commit 243ccf6932d97a3d100de5a2a7b102e1b2dc8cb2 (tag: v0.0.2)
Author: anarcher
Date:   Tue Dec 5 21:09:21 2017 +0900

    Bump version: 0.0.1 → 0.0.2

commit 9e8ff3f08a1039cc10d93749aa805e939cf28f73 (tag: v0.0.1)
Author: anarcher
Date:   Tue Dec 5 21:08:17 2017 +0900

    Bump version: 0.0.0 → 0.0.1

govvv

govvv is go binary versioning tool that wraps the go build command. Go provides access to setting variables by compile time linker flags. govvv provides easy versioning for go versioning even I don’t know that --ldflag of go build.

govvv install -pkg github.com/pkg/version github.com/cmd/

I just created version/version.go

package version

var (
	Version, GitCommit, GitState, BuildDate string
)

Because I make new VERSION file with bumpversion, govvv adds a Version variable from VERSION file to my version package. I like to seperate version variable with main.go. version variable can be used in another ways. (e.g. metric labels, api version call..)

$cmd -v
Cmd version 0.8.4 git=2639d4e build=2017-12-05T15:57:13Z

drone

drone is an open source continuous delivery tool. Interesting features of drone are that all tasks in drone is docker containers and drone’s yaml configure file is a superset of docker-compose configure file.

clone:
    git:
        image: plugins/git
        network_mode: host
        depth: 1
pipeline:
    test:
        image: golang:1.7.1
        commands:
            - make deps
            - make test
            - make test-ci
    docker:
        image: plugins/docker
        dockerfile: Dockerfile
        repo: app 
        force_tag: true
        tags: ${DRONE_TAG}
        when:
            event: tag
    slack:
        image: plugins/slack
        webhook: https://hooks.slack.com/
        when:
            status: [ success, failure ]

If repository tag hooks is enable in drone settings (default disable),git commit tag will sync up with docker tag. This is simply how to use the tools for releasing and versioning.

If you install the docker machine tool,you can use it like below:

$docker-machine ls
NAME    ACTIVE   DRIVER       STATE     URL                        SWARM
host1            generic      Running   tcp://192.168.99.100:2376   host1 (master)
host2            generic      Running   tcp://192.168.99.101:2376   host1
host3            generic      Running   tcp://192.168.99.102:2376   host1
demo0            virtualbox   Stopped                              
demo1            virtualbox   Stopped                              
demo2            virtualbox   Stopped                              
demo3            virtualbox   Stopped                              
infra            virtualbox   Stopped      

$docker-machine ssh host1
...


$docker $(docker-machine config host1) ps 
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
ea13099c15d3        swarm:latest        "/swarm join --addr 1"   7 weeks ago         Up 4 days           2375/tcp            swarm-agent

...

It’s useful to use docker command with docker machine command to connect docker engine on multi hosts.

docker-machine config is just printed like below.

$docker-machine config host1
--tlsverify --tlscacert="/home/anarcher/.docker/machine/machines/host1/ca.pem" 
--tlscert="/home/anarcher/.docker/machine/machines/host1/cert.pem" 
--tlskey="/home/anarcher/.docker/machine/machines/host1/key.pem" -H=tcp://192.168.99.100:2376

As you know,the bash command substitution can make the output of docker-machine command to replace the command itself. It’s one of the funny things using unix shell, too. :-)

Docker machine keeps the configuraion files which are information to connect on docker hosts to ~/.docker/machine/. If you want to share it with the others,you just copy it and share it.

Docker machine is based on ssh authentication to set up docker host nodes. So you can log in hosts to use docker-machine ssh [name].

Docker machine has many drivers that represent the virtual environments.The virtual environments are local linux,AWS,Digital ocean and many more. You can also add a existed Docker host to use driver none or if the host doesn’t has a docker engine,you can use the driver generic to install docker engine.

Docker machine has many options. So I have been using grep command with Unix pipe for searching the right command.

$docker-machine create -h | grep digi
   --digitalocean-access-token              Digital Ocean access token [$DIGITALOCEAN_ACCESS_TOKEN]
   --digitalocean-backups                   enable backups for droplet [$DIGITALOCEAN_BACKUPS]
   --digitalocean-image "ubuntu-14-04-x64"  Digital Ocean Image [$DIGITALOCEAN_IMAGE]
   --digitalocean-ipv6                      enable ipv6 for droplet [$DIGITALOCEAN_IPV6]
   --digitalocean-private-networking        enable private networking for droplet [$DIGITALOCEAN_PRIVATE_NETWORKING]
   --digitalocean-region "nyc3"             Digital Ocean region [$DIGITALOCEAN_REGION]
   --digitalocean-size "512mb"              Digital Ocean size [$DIGITALOCEAN_SIZE]

Basically It’s a convenience tool which looks like other docker tools. But unlike ansible or chef, It only care for Docker engine. If you want to host configuration, You should use other tools with docker-machine.

장표는 매우 간단하게 구성하고 데모에서 많은 이야기를 하고 싶었는데. 프로젝터설정부터 힘들어서 준비했던것을 절반밖에 이야기하지 못한것 같다.

Docker Swarm은 다른 클러스텅 시스템과 다른 부분들이 있다. 가장 큰 다른 점은 Docker에서 만들었다는 것. 즉 coreos/fleet이 Distributed Init System을 표방하는 것과 비슷하게 Swarm은 Docker-native Clustering System을 이야기한다. ¹

즉 다음과 같은 확장으로 Docker Interface(CLI/API)을 유지하고 싶어 한다.

docker run -d nginx-logger -e affinity:container==nginx nginx-logger

Google의 k8s나 다른 클러스트링 도구는 각자 자신만의 개념과 그 개념의 이해를 사용자에게 수반하게 만드는데. Swarm의 가장 큰 장점은 이러한 학습을 최소화 할수 있다는 점이 아닐까 싶기도 하다. ²

물론 이러한 접근이 쉽게 풀수 있는 문제를 어렵게 풀수 있는 여지가 있기도 하다.

개인적으로는 Docker의 성공이 기술이 아니라 일종의 사용성에 기인한거라면 Swarm도 이러한 장점을 잘 이해하고 있다는 생각도 든다.

ps) 하지만 아직 0.1.0 (HEAD)이고 프로덕션에서 쓰기에는 어리다.

go tool은 개인적으로 불만이 많은 도구이다. 특히 go get은 여러가지 기능의 부족으로 당황스러움을 느끼게 한다.

가령 go get은 scm(git,hg…)에서 직접 가져온다. 하지만 언제나 master branch의 최신을 가져온다. 즉 버져닝(versioning)에 대한 부분이 없다.

그리고 go get은 상대경로에 대한 인식을 하지 않는다. 언제나 $GOPATH부터 절대 경로로 패캐지를 임포트해야 한다. (언어의 제안사항이 아님)

go get에 특정 브랜치나 특정 태그(버젼)을 추가하자는 이야기는 go-nuts에 많이 (주기적으로) 나오는 이야기로 알고 있다.

개인적인 생각으로는 특히 오픈소스에서 버젼은 일종의 대화의 좋은 재료라고 생각한다. 구글안에서 처럼 항상 master branch가 stable하다고 하기에는 힘들다.

원래 하려는 이야기는 Versioning이 아니었는데.하튼 Vengo는 Python의 virtualenv처럼 여러 Go환경을 구성할수 있는 프로젝트이다.

Vengo은 Go 자체도 설치해준다.

vengo install -b 1.4

Python virtualenv 에 친숙하다면, 그리 어렵지 않게 사용할수 있을것 같다.

하나 궁금한 점은 이미 만들어진 환경에 go의 버젼을 변경할수 있는지이다. (다시 만들어도 되겠지만)

Go에서 외부 라이브러리 의존성 관리를 위해 여러 도구들이 있지만. 여러 오픈소스에서 가장 많이 사용하는 도구는 아마 Kz가 만든 godep 일것이다.

godep은 현재 패캐지와 의존성이 있는 패캐지들의 정보를 Godeps 디렉토리에 json포맷으로 저장하고 관련 패캐지들을 Godeps/.workspace에 복사한다.

godep을 사용하는 많은 프로젝트가 사용하는 외부 패캐지들을 이렇게 자신의 git 저장소에 저장해서 사용한다. GoogleCloudPlatform/kubernetes , codeos/etcd

Vengo랑 함께 사용하면 Godep으로 vendoring되어 있는 패캐지들은 현재 환경에 godep restore해서 사용하고 변경된 현재 환경을 godep save해서 사용할수 있다.

요즘 내가 사용하는 방식이다.

godep에서 외부 패캐지를 다 내 저장소에 저장하는 것에 대한 것이 scm을 일종의 디스크로 사용하는 느낌이라서 좋은 방법이 아니지 않나 하는 생각도 든다.

즉 npm이나 rubygem이나 docker registry처럼 scm와 연동된 패캐지 호스팅 서비스등이 있어야 하지 않나 라는 생각인데. Go에서도 비슷한 시도가 있었지만 대중적으로 인기가 있진 않다. (링크를 찾지 못하겠다.)

오픈소스 커뮤니티에서 여러가지 시도가 있으며, Python virtualenv 처럼 정리되어 go tool에 좋은 것이 포함되었으면 싶다. (다양성과 효율성이란 시점에서도 이런 움직임이 있어야 한다고 생각한다.)

• PackageManagementTools

docker의 장점은 대개 두가지로 이야기 할수 있겠다.

• Portability (이식성)
• Repeatability (반복성)

이식성(Portability)은 가장 크게 얻는 이점은 개발환경과 실제 프로덕션 환경의 차이를 설정변수 몇개로 축소할수 있다는 점이라고 생각한다. 여러 환경(개발,테스트,프로덕션)을 일치시키기 위한 별다른 노력을 할 필요 없다는 점이 가장 큰 매력으로 생각한다. 물론 자바와 비슷하게 한번 작성하면 어디서든 동작한다는 것이 여러 Host 환경에서 동작할 수 있다는 점도 무시할수는 없겠다.

반복성(Repeatability)은 결국 컨테이너와 이미지를 생성/변경/실행이 빠르고 가볍기 때문에 지속적인 통합(Continuous Integration)과 배포(Deployment) 이득이 있다.

아래 장표에서 밴치마크 부분은 docker 0.7/linux 3.8 기준으로 작성되어 있는 것을 참고했다. linux 3.11에서 network부분의 향상이 있어서 지금 docker 1.0/linux 3.11 에서의 network 성능은 Host와의 차이가 크지 않을 것이라고 생각한다. (자료를 찾아보거나 테스트해 볼 필요는 있어보인다)

읽어야 할 글들을 Kindle에 던지는데,뭘 킨들에 던졌는지 기록해 두면 좋을 것 같아서 적어본다.

Go’s power is in emergent behavior

• http://www.onebigfluke.com/2014/04/gos-power-is-in-emergent-behavior.html
• golang의 interface의 특징을 두가지 예(http.HandlerFunc,opaque type)을 가지고 설명. 저번에 있었던 gophercon에서 들은 내용에 대한 글.

Go Parallel 1,2

• https://software.intel.com/en-us/blogs/2013/06/18/go-parallel
• https://software.intel.com/en-us/blogs/2014/04/13/go-parallel-2
• 고루틴에 대한 예제와 함께 짧게 고루틴을 알수 있는 글.

Go: Best Practices for Production Environments

• http://peter.bourgon.org/go-in-production/

• soundcloud에서 go 프로젝트를 하면서 생긴 팁들을 나열.

• 개인적으로는 python의 virtualenv처럼 여러 GOPATH을 관리 할 수 있으면 좋겠다. (아마 이미 관련 도구가 있을 듯 하기도 하다.)

Why I like Go?

• https://gist.github.com/freeformz/4746274
• https://news.ycombinator.com/item?id=5195257

The Case for React.js and ClojureScript

• http://murilopereira.com/the-case-for-reactjs-and-clojurescript/#/

• react.js와 clojurescript에 대한 이야기.

• react.js은 거칠게 이야기해서 MVC중 V에 해당한다.

• 개인적으로 관심을 가지고 있는 프론트엔드 프로젝트중 하나.

Load balancing with Vulcan and Etcd

• http://vulcan.ghost.io/intro/

• docker을 만든 dotcloud의 https://github.com/dotcloud/hipache는 redis을 backend data로 사용하는데 반해,

• vulcan은 etcd에 있는 데이터를 기반으로 동적으로 로드밸랜싱을 해주는 리버스 프록시 프로젝트이다.

• go로 만든 프로젝트.

Why we don’t hire programmers based on puzzles, API quizzes, math riddles, or other parlor tricks

• http://signalvnoise.com/posts/3071-why-we-dont-hire-programmers-based-on-puzzles-api-quizzes-math-riddles-or-other-parlor-tricks

• http://gettingreal.37signals.com/ch08_Kick_the_Tires.php

• 실제 코드와 이슈로 좋은 프로그래머를 찾는 것이 특정 퀴즈로 찾는 것보다 성공률이 높다.

• 함께 일해보는 것 만큼 좋은 인터뷰는 없다.

Immutable Infrastructure with Ansible and Packer

• http://blog.codeship.io/2014/05/08/ansible-packer-immutable-infrastructure.html

나름 고생스러워서 기록삼아 포스팅.

읽어야 할 글들을 Kindle에 던지는데,뭘 킨들에 던졌는지 기록해 두면 좋을 것 같아서 적어본다. 이번달은 읽은 글들이 많지가 않다. T_T

Go and Package Versioning

• http://zduck.com/2014/go-and-package-versioning/

“My dream is for go get to support a version number component in the import path. So github.com/jpoehls/gophermail would fetch the HEAD of the repository as it does today. github.com/jpoehls/gophermail#v1 would fetch the v1 branch or tag.”

http://gopkg.in 을 사용하면 github에 한해, branch,tag로 구분되어 있는 버젼을 패캐지버젼을 사용할수 있게 된다.

일반적으로 버젼이 존재함에 있어서 생기는 문제가 있어서 go tools에서 버젼을 지원하지 않는 것은 감정적으로는 조금은 무책임하다고 생각한다. 저자처럼 go get에서 branch나 tag을 지원해주는 정도는 무난하지 않나 싶기도 하다.

지금 go get은 branch나 tag을 go version에 대응해서 사용하고 있다.

Write code every day

• http://ejohn.org/blog/write-code-every-day/

“the feeling of making progress is just as important as making actual progress. " - Inspirational blog post

Throttled: Guardian Of The Web Server

• http://0value.com/throttled--guardian-of-the-web-server

http 요청 접근에 대한 여러가지 방법(rate-limiting,메모리 사용에 대한 요청에 허가 등)을 구현한 라이브러리.

go 표준 라이브러리인 http.Handler에 적용해서 사용할수 있다

Go Concurrency Patterns: Pipelines and cancellation

• http://blog.golang.org/pipelines

goroutine은 동시성을 얻기 위한 언어도구이다. 각 단계가 독립적으로 각 입력과 출력을 다른 동시성을 가지고 있는 파이프라인을 고루틴으로 가지고 어떻게 구성하는지와 동작의 취소에 대한 구현방법 이야기.

Defining HTTP Status Codes

• http://refugeeks.com/defining-http-status-codes-list-http-status-codes/ : Defining HTTP Status Codes

고양이 사진으로 보는 http 상태 코드들.

Some Thoughts on Go and Erlang

• http://blog.erlware.org/2014/04/27/some-thoughts-on-go-and-erlang/

제목과 달리 (Erlang에 비해) Go의 단점에 대한 이야기. 결론적으로 결함 감내(Fault tolerant )와 낮은 지연 시간(low latency)에 Go가 적합하지 않다는 내용.

Fault tolerant이 필요한 복잡한 시스템에서 Erlang에 비해 상태를 공유하는 다른 언어처럼 쉽게 망가지고, Go의 현재 GC가 Global mark-and-sweep이기 때문에 Low latency을 얻기 힘든다는 내용이다.

읽어야 할 글들을 Kindle에 던지는데,뭘 킨들에 던졌는지 기록해 두면 좋을 것 같아서 적어본다.

Why Atom Can’t Replace Vim : Learning the lesson of vi

Atom이 Emacs의 확장가능성은 가질수 있지만, Vi의 조합가능성에 대해서는 배운 바가 없다는 글.

조합가능성에 대한 글로는 http://blog.dahlia.kr/post/78940164278 홍민희님의 글과 함께 보면 좋다.

내가 생각하는 조합 가능성은 명령어들의 조합이 명령어와 차별 받지 않고 같은 취급을 받는 것이 아닌가 싶다. 유닉스의 파이프로 연결하여 또 하나의 명령어를 만들듯이.

또 하나의 생각은 Emacs은 어떤 기능이 필요할때 플러그인으로 확장해서 기능을 구현하지만, Vi은 외부 명령어와의 조합으로 기능을 구현한다라는 점.

Sane Concurrency with Go

공유되는 상태의 병렬로 상태를 바꾸려고 할때, 뮤텍스가 아닌 고루틴과 채널을 이용하여 동기화하는 방법과 디자인에 대한 글

상태를 가지고 있는 객체 내부에 하나의 고루틴 이벤트 루프를 두어서 동기화를 하고,버퍼가 없는 채널을 이용하는 메소드 인터페이스를 구성하여, 외부에서는 간단히 일반적인 호출을 하는 디자인을 설명.

Heka의 기본적인 디자인 패턴이기도 함.

TwistedPython의 저자 Glyph의 Unyielding에 있는 계좌이체 예제를 Go언어의 고루틴과 채널을 이용하여 구현하는 방법에 대한 글.

Unyielding

TwistedPython의 저자 Glyph의 동시성에 대한 글.

Why Threads Are A Bad Idea (for most purposes)

대부분의 경우 쓰레드가 왜 나쁜 아이디어인지에 대한 키노트.

많은 경우 쓰레드보다는 이벤트 방식이 좀더 유용하다. (GUI 이벤트,분산 시스템 등등..) 쓰레드가 이벤트보다 강력하지만 그 만큼 위험하다. 쓰레드는 CPU기반 동시성이 필요할때만 사용하자.

etcd + ansible = crazy delicious

ansible은 기본적으로 파일을 기반으로 접속할 서버를 찾거나 기타 정보를 얻는다. ansible에서 이러한 정보를 인벤토리라고 부르는데, ansible tower라는 인벤토리 서버와 웹 관리도구을 상용으로 제공하기도 한다.

ansible에는 동적 인벤토리라는 기능을 제공하는데. 이 기능을 이용하여 인벤토리를 etcd에 저장하고 ansible을 사용하는 방법에 대한 글.

Datomic Rationale Why did we build Datomic?

기존의 데이터베이스는 Client/Server구조를 기본적으로 가진다. Scalability을 위해 Server을 Clustering을 하거나 Sharing,Replicating을 하게 된다. 그리고 Client(Application)에서 일종의 Caching을 구성하게 된다.

Datomic은 이러한 전통적인 데이터베이스의 구성요소를 해체(Deconstruct)해서 다음과 같은 구조로 각 요소에 대한 좀 더 효율성(Efficiency)과 확장성(Scalability)을 구성할수 있도록 한다.

• Peers : LiveIndex,Local Cache,Query (쿼리 할 때 Live Index,Local cache를 참고한다 (모든 데이터에 대한 캐쉬가 각 Peer에 존재하는 듯 하다(기본적으로))
• Transactor : 각 Peer의 Writes에 대한 모든 Transaction을 담당한다.
• Storage services : 영속적인 스토리지 서비스에 대한 인터페이스
• Cache : Optional

BUILDING YOUR FIRST APP ON COREOS: START TO FINISH

mac osx에서 (다른 OS도 가능하겠지만) coreos와 fig등을 이용하여 wordpress을 사용하는 방법을 적은 글. 개인적으로 fleet에 대한 관심이 생기게 된 글이다.

우선 사용한 라이브러리는 vibe.d와 Backend Server와의 통신을 위해 thrift이다.

vibe.d은 기본적으로 redis와 mongodb을 지원하지만, Thrift에 대한 지원은 없다.

vibed의 Writing native database drivers - and a new MySQL driver port 을 참고하여 TSocket을 vibe.d의 TCPConnection을 사용하도록 만들어서 사용했다.

(지금으로써는) 간단한 REST API Server이라서 언어적인 기능을 많이 사용하지는 않았지만,간단히 D언어 사용에 대한 평을 해보자면,

• 타입시스템에 반하여 암묵적으로 컴파일러가 처리하는 부분이 없다.
• 함수적 프로그래밍(Functional Programming)위해 만들지 않고, 함수적 프로그래밍의 개념을 절차적인 언어의 기반에서 적절하게 적용했다.
• 물론 객체지향 프로그래밍을 지원하며, 객체지향적인 프로그래밍에 필요한 참조기반의 의미론과 이에 반해 struct등을 사용한 값기반의 의미론을 모두 지원한다.
• 가비지콜렉션을 지원하지만, 명시적으로 메모리 할당과 해제를 할수도 있다. (하지만 난 거의 그렇게 사용하지 않았다)
• 동시성에 대한 설계에서 erlang등의 ActorModel에 영향을 받아서 설계되었다. (하지만 다른 언어처럼 잠금기반의 라이브러리도 지원한다)

특히 The D Programming language 이 책은 D 언어에 관심이 없더라도, 한번쯤 읽어 볼만 하다.저자가 언어의 디자인 결정을 왜 했는지에 대한 이야기를 정말 재미있게 풀었다.

크롬북을 샀다.

크롬북의 가장 큰 장점은 가격이다. $199에 이정도 노트북을 살수 있다는 것은 분명 매력적. 정말로 크롬 웹 브라우저만 있다. 흠…

• 좋지 않은 디스플레이 (흐릿한 디스플레이는 C720의 가장 큰 하드웨어 단점이다)
• 8시간 사용 가능한 배터리 (하스웰 기반 CPU이 주는 혜택. 8시간이상 되니까 핸드폰처럼 충전기를 가지고 다니지 않게 되었다)
• 내 아이폰과 같은 용량인 16기가 SSD.

나의 개발환경을 기본적으로 한쪽 화면에 터미널(들),또 다른 화면에는 웹 브라우저(들)뿐이다. 크롬OS는 개발자 모드로 shell을 사용할수 있으므로, 코딩하는게 크게 문제는 없다.

Acer C720의 개발자 모드 사용법은 http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-c720-chromebook 참고.

Ctrl + alt + t 을 누르면 crosh가 뜬다. 하지만 크롬탭으로 실행되기때문에 단축키 충돌등이 발생한다.

crosh window 을 설치하면 window으로 따로 띠우기 때문에 사용하기 좀 더 편하다. (문제는 터미널을 탭으로 더 띠울수 없다)

그리고 Ubuntu/Debian을 사용하기 위해서 crouton을 설치했다. (cli-extra으로 CLI만 사용하도록 설치)

거의 회사에서 쓰는 ubuntu와 비슷하다. 단 다음과 같은 사용시에 단점들이 있긴 하지만.

• crosh window에서 한글이 되지 않는다.
• docker가 설치되지 않는다. chromeos의 linux kernel이 docker가 필요하게 구성되어 있지 않다.

싸고 터미널과 웹만 있으면 코딩이 가능한 사람들에게는 추천할 만하다고 생각한다.

코세라 코스는 끝나고 인증서를 주는데 (물론 코세라 강의를 잘 들었다 정도의 의미이다.) 저번에 Function programming In Scala 다음으로 힘들었다.

강의 자체는 C++0x까지 있어서 C++ 언어를 한번 정리하는 점으로는 좋았다. 하지만 숙제는 C/C++ 지식만 가지고는 풀수가 없었는데. 특히 알고리즘 기반의 숙제는 C++ 학습만 생각하고 시작했던 나에게는 조금 당혹스러워 했었다고 해야 하나.

나름 잘 모르는 알고리즘도 알게 되고 나쁘지는 않았지만. 거의 한달간 주말은 없었다고 해도 무방했다.

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton

Chef을 써보면서, 요리에 관련된 메타포를 사용하여 Chef 구성요소들의 이름들을 잘 지었다는 생각이 든다. Chef을 구성하는 요소에 대한 설명을 간단히 몇개 적어 보자면:

• Chef : 요리사,Server Configuration Project
• Recipe : 요리법,어떤 작업을 할지 서술하는 목록
• Cookbook: 요리책,Recipe의 모음집.
• Knife : 칼 요리도구,Chef의 CLI 도구
• Node : 구성 작업할 서버
• Workstation : 작업장, Knife등의 도구를 통해 Chef에 작업을 하는 머신.
• Data bag : Chef Server에 JSON기반으로 저장되는 데이터
• Run list : Node에 작업할 목록(Cookbook의 Recipe나 다른 Role을 포함할수 있다)
• Attribute : 노드의 속성. Node와 Cookbook,Role,Environment에서 정의될수 있고,순서규칙에 따라 overide가 된다.
• Role : Run list와 Attribute을 가지는 설정

물론 모든 단어가 요리에 관련된 단어는 아니다. 좀더 명확하게 설명할수 있는 요소는 굳이 사용하지 않은 듯 하다.

좋았던 점은 Data bag과 Search 부분이다. 구성에 대한 정보를 Data bag의 Item으로 등록해두고 Recipe에서 사용하는 방식은 기능과 정보를 나누어서 관리 할수 있어서 데이터에 따른 recipe 사용이 좀더 편해진다.

특히 Chef REST API을 가지고 서버 구성하는 애플리케이션을 만들때, 따로 DB을 구성하지 않고 Chef의 Data bag을 사용할 수 있다 (트랜잭션이 크게 중요하지 않다는 판단하에).

구성이 끝나면,Chef의 Node에 추가되는데. Node의 정보(cpus,mem…)등도 함께 등록되기 때문에 현재 가용중인 서버들의 정보를 얻기에 쉽다.

이 부분에서 좀 아쉬운 부분은 구성 작업이 성공했는지 실패했는지에 대한 정보가 Node에 없어서 관련 Recipe을 만들어 줄 필요가 있다.

그리고 Chef 문서에도 있는 데, Databag이나 Cookbook등을 SCM(버젼관리) 저장소를 쓰는 것을 추천하는데. Chef server에 git이나 hg등의 scm 기능이 추가되어도 괜찮지 않을까 생각이 든다.

또 다른 아쉬운 점은 Chef은 기본적으로 하나의 노드에 대한 작업에 대한 부분만 고려되어 있는 듯 한 느낌이다. 즉 여러 노드를 병렬/순차적으로 작업해야 할때에 대한 기능이 직접적인 지원이 없다. (예를 들어 AWS의 Cloudformation 같은 기능을 말한다)

자체적으로 데이터 스토어가 있다는 점, 중앙 관리가 가능하다는 점에서는 Chef 사용에 있어 좋은 점이라고 생각된다.

Chef을 사용하지 않고 하려면 어떤 도구들을 사용하면 될까? 개인적으로는 Ansible와 Zookeeper을 가지고 비슷하게 구성해볼수 있지 않을까 생각된다.

동기

Soundcloud에서 이런 저런 Podcast을 자주 듣는 편이다. 주로 크롬 웹 브라우저에서 듣는데. 보통 탭이 한두개가 아닌지라 Soundcloud에서 듣다가 음악이나 방송을 끄거나 하려면 종종 열려 있는 탭에서 찾아야 하는 점이 불편했다. 그래서 크롬 익스텐션으로 만들어서 쉽게 (혹은 빠르게) 재생/중지를 할수 있으면 좋지 않을까 싶었다.

만들고 나서, soundcloud button extension 으로 구글링해보면, opera용 add-on 이 있기는 하다. (사실 설명 부분은 살짝 베끼긴 했다. 영어 실력으로 부족으로.;ㅁ;)

개발

사실 크롬 익스텐션을 만들어 본적이 없었기 때문에, 2시간-프로젝트(2HourProject)가 될거라고는 생각하지 않았다. 그래도 https://github.com/outsideris/gittip-links 코드도 좀 보고,구글 튜토리얼도 보면서 이것저것 HelloWorld 수준의 코드를 만들어 보면서 만들긴 했다. 대충 업로드와 이미지 작업 빼고 5시간 정도 걸린듯 하다.(카페에서 친구와 잡담도 하고 멍하니 있기도 해서 정확한 시간은 모르겠다.;)

하면서 아이콘 이미지 만드는 것 하나 잘 모른다는 걸 알았다. Soundcloud의 버튼을 쓰고 싶었지만, 배경을 투명하게 만드는 것도 하기 힘들어서 포기하고 http://findicons.com/icon/248309/play 을 가져다가 썼다. (라이센스는 프리웨어,비상업)

이미지 툴도 없어서 GIMP을 맥에 설치할까 했지만, 웹에 있는 http://pixlr.com/editor/ 을 알게 되어서 조금 써볼려고 해봤다. (결론은 실패.:-( )

크롬 익스텐션의 구조는 매우 간단해서 background page에 soundcloud page에 반응하는 content script가 dom을 읽어서 Message passing 하는 구조이다.

크롬 익스텐션이 의외로 어렵진 않았는데, 간단한 것을 만들어서 크게 내부 구조를 알 필요가 없긴 했다.

에필로그

나 혼자 쓰게 될것 같은데. ㅎㅎ 우선 간단한 아이디어라도 구현해보니 나쁘지 않았다. 만들자 마자 올려서 어떤 버그가 있는 지도 안알라줌. (나도 모르지만 존재 여부는 당연히.. ;ㅁ;)

소스는 여기 에 있고,익스텐션은 여기에 있다.

ps)재미삼아 오마주한 프로젝트의 블로그 글을 따라했다. ㅎㅎㅎ

REST(Representational State Transfer) API는 선언적인 방법으로 리소스(Resource)의 표현되는 상태를 변화(GET,POST,PUT,PATCH,DELETE…)시키는 인터페이스라고 할수 있다.

그리고 이러한 리소스의 상태에 따라 시스템이 동작하는 구조라고 생각한다.(직접 시스템의 동작을 명령하는 인터페이스를 가진 것이 아닌.)

REST API을 설계할때, RPC API 설계개념을 가져와 작성하게 되면 HTTP Methods(GET,POST,PUT…)으로 동작으로 명령을 정의하게 되어서 표현제약이 발생하고,결국 리소스을 가져다가 특정 동작을 정의하게 된다.

책 “일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙"에서는 리소스 프로토타입에서 컨트롤러라는 이름으로 이러한 절차적인 호출을 위한 프로토타입이 있기는 하다.

하지만 기본적으로 리소스의 상태를 변화시키는 방법으로는 만들수 없는 경우에 사용되는 프로토타입이라고 생각된다.

Master가 특정 Task를 Worker에 요청을 하려고 하는데, 여러가지 이유로 Master가 Worker에 접속을 하는 구조가 아닌, Worker가 실행할때 Master에 접속 할수만 있다고 하자.

(특히 내부 IP만 가진 Worker라면 Master가 Worker에 접속을 할수가 없다.)

ThriftRPC나 MsgpackRPC의 구조를 보면, Client/Server 구조로 Client가 Server의 Procedure을 원격 실행하는 방법만 지원한다.

(Thrift에서 양방향 RPC을 쓰고 싶다면 http://joelpm.com/2009/04/03/thrift-bidirectional-async-rpc.html 을 참고,써보지는 않았다. 자바만 지원.)

밑으로 내려가서 보면, TCP은 기본적으로 Full-duplex 데이터 전달이 가능하다. TCP, 또는 웹이라면 WebSocket 기반으로 Bidirectional RPC을 만들면 가능하다고 할수 있는데.

RPC을 만들기 보다는 기존의 RPC 라이브러리를 사용하고 싶어서, 다음과 같이 구성을 해보려고 한다.

• MasterServer는 두개의 정의된 Port를 Listen 한다.
• 한 Port는 Client가 Server에 RPC하는 Port이고,
• 나머지 한 Port은 Server가 Client에 RPC하는 Port이다.

Connection이 두개 생기기는 하지만, 기존의 RPC 라이브러리를 사용하여 양방향 RPC을 가능해진다. golang의 net/rpc 을 가지고 간단히 Server에서 Client에 Remote Procedure Call을 해 볼수 있다.

package main

import (
    "net"
    "net/rpc"
    "log"
    "time"
    "fmt"
)

func requestToClient(conn net.Conn) {
    client := rpc.NewClient(conn)
    var out string

    for i := 0 ; i < 5 ; i ++  {
        log.Println("S: echo.echo")
        client.Call("Echo.Echo",fmt.Sprintf("%s:%d","hello client!",i),&out)
        log.Println("E: echo.echo",out)
        time.Sleep(100 * time.Millisecond)
    }
}

func main() {

    li,err := net.Listen("tcp",":1234")
    if err != nil {
        log.Fatal(err)
    }

    log.Println("Starting server")

    for {
        conn,_err := li.Accept()
        if _err != nil {
            log.Fatal(err)
        }

        log.Printf("Connected client: %v",conn.RemoteAddr())
        go requestToClient(conn)
    }
}

Client가 접속을 하면 Server은 접속한 Connection을 가지고 rpc client을 만들어서 요청을 한다.

package main
import (
    "net"
    "net/rpc"
    "log"
    "fmt"
)


func main() {

    echo := new(Echo)
    rpc.Register(echo)

    conn,err := net.Dial("tcp",":1234")
    if err != nil {
        log.Fatal(err)
    }

    go rpc.ServeConn(conn)

    var input string
    fmt.Scanln(&input)

}

Client은 Server에 접속한 후에 등록된 Procedure의 요청을 받기 위해 rpc.ServeConn을 사용한다.

개인적으로 MongoDB을 많이 좋아하지는 않지만(비슷한 것으로 RethinkDB가 더 맘에 든다.) 그래서 오히려 온라인 강의를 들어서 배우는게 어떨까 싶었다.

10gen(MongoDB 제작사)은 커뮤니티를 만드는 작업을 굉장히 잘한다는 생각이 든다. 이런 온라인 코스도 코세라만큼 구성 자체를 잘 되어 있는 편.

구글인앱빌링 사용 모듈 구현사례

안드로이드 프로그래밍을 해본 경험이 없어서,잘 알지 못하는 분야이다. 구글의 인앱빌딩 지원을 버젼별로 상세히 설명되어있고,적어도 (나처럼 무경험자에게는) 어떻게 동작하는지 알수 있는 자리이었다.

나중에 안드로이드 프로그래밍을 한다면,그때 다시 한번 찾아 볼듯 하다.

Go Lang for Java Programmer

GoLang에 대한 기본적인 문법과 개념을 설명했다. 발표에 대한 연습을 많이 했다는 걸 느낄수 있었다.

사실 나는 Go에 관심이 있어서 DevFest에 참가한 것이라고 할수 있는데. 기본적인 GoLang에 대한 차분한 설명을 잘 들을수 있었다.

Chrome UI Frameworks

크롬OS의 Arua UI에 대한 기본적인 설명을 하는 세션이었다. Arua UI는 원도우 UI 시스템인데, 사실 난 크롬OS에서 크게 감흥이 없어서 그런지 UI을 구경하는 자리이었던것 같다.

기억이 남는 부분은 GtkWindow을 쓰지않고 구글은 독자적으로 Arua UI을 만들었다는 점. 기능한 어떤 이점이 있는지 모르겠다.

How to live like goer

가장 재미있게 들은 발표이다. Python에서 Go으로 넘어가면서의 기록이라고도 할수 있는데. 무언가 정확한 정보를 전달하는 것보다 사변적으로 이런 저런 다른 이의 생각과 경험을 알수 있어서 그런지 가장 즐거웠다.

AnguarJS

사실 Web Frontend에서 ServerSideRendering와 ClientSideRendering에 대해 갑을논박이 많은 듯 하다. 이부분은 사실 IRC(오징어의 #codeport에 놀려 오시면 종종 이런 이야기하는 무리?를 발견할수 있다.)에서 사람들과 이야기 하곤 했는데. ClientSideRendering에서 Backbone.js보다 더 요즘 인기를 얻고 있는 프레임워크이라서 관심이 있었다.

Backbone.js보다 좀더 일체화된 구성을 가지고 있는데. 많은 부분이 구성이 되어 있어서 Backbone.js보다 좀더 쉽게 시작할수 있는 것 같다.

요즘 Backbone.js에서는 view dispose에 대한 이슈로 패치가 추가되었는데. AnguarJS에서는 어떤식으로 객체의 확득과 소멸을 하는지 궁금해졌다.

특히 One page application에서는 JS의 메모리 관리가 큰 이슈가 된다고 생각한다.

Concurrency is not parallelism

RobPike의 “Concurrency is not parallelism"을 GoLangUserGroup에서 다시 발표한 것이다. CSP의 개념을 가지고 만든 동시성을 지원하는 Golang의 goroutine으로 병렬성을 어떻게 얻는지에 대한 이야기이다.

Concurrency은 프로그램의 특성이고,Parallel은 기계의 성질이다. 어떤 프로그램이 동시에 여러 루틴이 돌아간다면 Concurrency한 것이고,이 프로그램이 정말 동시에 동작할지는 사실 머신에 따라 다르다. 싱글 코어에서도 Concurrent하게 돌겠지만(시분할), 정말 병렬적으로 돌려면, 멀티코어상에서 가능하다.

GoLang의 동시성 지원은 멀티코어 시대의 위기?를 해결하고자 이슈를 얻고 있는 함수형 프로그래밍(물론 이것 하나때문에 요즘 관심을 받는 것은 아니지만)에 대한 생각을 다시 하게 만들었다.

어떤 goroutine들은 Concurrent을 한 Thread에서만 획득하고 싶다거나(ThreadContention을 피하고 싶을 경우라든가) 하는 구성을 어떻게 하는지 궁금해졌다. 예를 들어,goroutine으로 PythonGenerator을 구성한다면 말이다.

오랜만의 컨퍼런스

사실 3일연휴이라서 여유가 있기에 올수 있었다. 나도 컨퍼런스에 대한 맘이 예전같지 않다.(응?;) 나름 지인들도 보고 공짜 점심도 먹을 수 있어서..;ㅁ; 즐거운 하루이었던것 같다. 아래는 발표자료 링크이다.

https://docs.google.com/a/enswer.net/folder/d/0B82z67M0_dLHWXdfNEtMQ2hYSXM/edit?usp=sharing

이번에 설계를 하면서, Twitter나 Facebook의 API을 참고하긴 했지만, 각각의 스타일의 차이를 알수는 있어도 좋은 디자인 규칙에 대한 정보를 얻기가 힘들었다.

특히 리소스 모델링 부분이 어려운데, REST API Design Rulebook을 참고하여 구성하고 있다.

Resource의 프로토타입을 제시

REST API Design Rulebook에서는 리소스의 원형을 다음과 같이 제시한다.

• 도큐먼트
• 컬렉션
• 스토어
• 컨트롤러

이중에서 가장 흥미로운 리소스 원형은 컨트롤러 리소스와 스토어 리소스이다. 컨트롤러 리소스는 사실 HTTP Method으로는 표현하기 힘든 행동을 리소스로 표현하기 위해 존재한다.

POST /alerts/23456/resend 

스토어 리소스는 기본적으로 클라이언트가 관리하는 리소스이다. (다른 3개의 리소스는 서버-사이드 리소스이다) 그리고 새로운 리소스를 만들지 못한다.

예를 들어, 서버에서 관리하는 리소스인 컬렉션 리소스에 어떤 도큐먼트 리소스를 포함(저장)하는 행동을 클라이언트가 스토어 리소스로 할수 있다. (이는 기존에 존재하는 리소스의 관계를 만드는(저장하는) 행동이기 때문에 새로운 리소스를 만든다고 할수 없는 것 같다)

개인적인 짧은 생각으로는 스토어 리소스라는 이름보다는 릴레이션 리소스 같은 이름이 좀더 명확한것이 아닌가 싶다.

이책의 저자는 이런 리소스 디자인을 가지고 Web Resource Modeling Language이라는 프로젝트를 하고 있지만,큰 호응이 있는 것 같지는 않다.

관례적으로 (예상되겠지만) 도규먼트는 단수 명사, 콜렉션은 복수 명사,스토어는 복수 명사,컨트롤러는 동사를 사용한다. http://www.wrml.org/modelingLanguage

이런 리소스의 원형(혹은 규칙)을 가지고 API을 만든다면 좀더 일관성이 있는 REST API을 만들기 좋지 않나 싶다.

강의도 좋지만, 숙제가 TDD기반으로 작성하여 작성한 코드를 코세라에 업로드하면 채점용 TestCase가 돌아서 채점이 된다. 이런 부분들의 준비가 굉장히 잘되어 있다.

정말 어려웠던 수업이기도 했다. =_=

map/reduce

map/reduce는 map의 결과가 하나의 reduce에서 같은 key으로 모이는 것 보장한다.로직에 따라 다르겠지만. 전체 갯수을 얻는 것이 아니라면 reduce을 늘리는 것이 성능에 좋다. (당연한 이야기이지만)

combiner

Disco 문서에서는 보기 힘든데, Hadoop처럼 combiner을 만들 수 있다. combiner은 일종의 accumulator인데. 각 map마다 map의 결과를 받아서 reduce에 넘기기전에 buffer을 가진 function(combiner)을 만들 수 있는데. 대부분의 경우 combiner을 만드는 것이 속도나 메모리 사용에 좋을 것 같다.

ddfs chunk size 와 map

ddfs에 데이터를 넣을때, 기본적으로 blob size은 64M이다. 문제는 mapper은 blob마다 할당되는데. 데이터가 좀더 넓게 펴져 있다면, 좀 더 많은 머신들이 map에 참여하게 된다. ddfs command에서는 chunk size을 바꿀수 없고. ddfs chunk으로 넣은 데이터를 원하는 size으로 짤라주는 작업이 필요하다. ¹

ddfs chunk 읽기

ddfs chunk도 일종의 mapreduce job으로 돌린다. ddfs xcat command처럼 chunk의 데이터를 읽으려면 disco_input_stream 으로 읽어야 한다. ddfs command도 python code이니. ddfs command code을 참고했다.

Disco vs Hadoop

대부분의 경우 단일 머신에서 계산을 비교하면 그냥 일반적인 계산 코드가 빠르다. 하지만 확장성이나 데이터를 분산해서 두고 규모가 커지더라도 대응할수 있게 만들려면 M/R이 나쁘지 않은 듯 하다.

내가 하는 Jobs들은 대용량의 데이터라기 보다는 많은 Jobs이 참여하는 구조이라서 (더군다나 계층적인 구조.. OTL) job들을 chaining해서 이전 reduce의 output이 다음 map의 input이 되는 패턴이 계층적으로 되어지니까 코드가 귀찮아 진다. (핑계 없는 무덤을 없더라는 속담을 생각하며. -_-)

Storm이나 Spark에서는 좀더 이런 구조에 적절할지 궁금하다. 그나저나 Storm은 이번달에 나오겠군.

• Github
• Bluesky
• Twitter