Sandboxed, Online Debugging of Production Bugs for SOA Systems

Sandboxed, Online Debugging of Production Bugs for SOA Systems Nipun Arora Software debugging is the process of localizing, and finding root-cause of defects that were observed in a system. In particular, production systems bugs can be the result of complex interactions between multiple system components and can cause faults either in the kernel, middleware or the application itself. Hence it is important, to be able to gain insight into the entire workflow of the system, both breadth-wise (across application tiers and network boundaries), and depth wise (across the execution stack from application to kernel). In addition to the inherent complexity in debugging, it is also essential to have a short time to bug diagnosis to reduce the financial impact of any error. Recent trends towards DevOps, and agile software engineering paradigms further emphasize the need of having shorter debug cycles. DevOps stresses on close coupling between software developers and operators, and to merge the operations of both. Similarly, agile programming has shorter development cycles called sprints, which focus on faster releases, and quick debugging. This trend is also reflected in the frequency of releases in modern SOA services, for instance Facebook mobile has 2 releases a day, and Flickr has 10 deployment cycles per day. Existing debugging mechanisms provide light-weight instrumentation which can track execution flow in the application by instrumenting important points in the application code. These are followed by inference based mechanisms to find the root-cause of the problem. While such techniques are useful in getting a clue about the bug, they are limited in their ability to discover the root-cause (can point out the module or component which is faulty, but cannot determine the root-cause at code, function level granularity). Another body of work uses record-and-replay infrastructures, which record the execution and then replay the execution offline. These tools generate a high fidelity representative execution for offline bug diagnosis, at the cost of a relatively heavy overhead, which is generally not acceptable in user-facing production systems. Therefore, to meet the demands of a low-latency distributed computing environment of modern service oriented systems, it is important to have debugging tools which have minimal to negligible impact on the application and can provide a fast update to the operator to allow for shorter time to debug. To this end, we introduce a new debugging paradigm called live debugging. There are two goals that any live debugging infrastructure must meet: Firstly, it must offer real-time insight for bug diagnosis and localization, which is paramount when errors happen in user-facing service-oriented applications. Having a shorter debug cycles and quicker patches is essential to ensure application quality and reliability. Secondly, live debugging should not impact user-facing performance for non bug triggering events. Most bugs which impact only a small percentage of users. In such scenarios, debugging the application should not impact the entire system and other users who are not triggering the bug. With the above-stated goals in mind, we have designed a framework called Parikshan1, which leverages user-space containers (OpenVZ/ LXC) to launch application instances for the express purpose of debugging. Parikshan is driven by a live-cloning process, which generates a replica (debug container) of production services for debugging or testing, cloned from a production container which provides the real output to the user. The debug container provides a sandbox environment, for safe execution of test-cases/debugging done by the users without any perturbation to the execution environment. As a part of this framework, we have designed customized-network proxy agents, which replicate inputs from clients to both the production and test-container, as well safely discard all outputs from the test-container. Together the network proxy, and the debug container ensure both compute and network isolation of the debugging environment, while at the same time allowing the user to debug the application. We believe that this piece of work provides the first of it’s kind practical real-time debugging of large multi-tier and cloud applications, without requiring any application down-time, and minimal performance impact. The principal hypothesis of this dissertation is that, for large-scale service-oriented-applications (SOA) it is possible to provide a live debugging environment, which allows the developer to debug the target application without impacting the production system. Primarily, we will present an approach for live debugging of production systems. This involves discussion of Parikshan framework which forms the backbone of this dissertation. We will discuss how to clone the containers, split and isolate network traffic, and aggregate it for communication to both upstream and downstream tiers, in a multi-tier SOA infrastructure. As a part of this description, we will also show case-studies demonstrating how network replay is enough for triggering most bugs in real-world applications. To show this, we have presented 16 real-world bugs, which were triggered Parikshan is the sanskrit word for testing using our network duplication techniques. Additionally, we present a survey of 220 bugs from bug reports of SOA applications which were found to be similar to the 16 mentioned above. Secondly, we will present iProbe a new type of instrumentation framework, which uses a combination of static and dynamic instrumentation, to have an order-of-magnitude better performance than existing instrumentation techniques. The iProbe tool is the result of our initial investigation towards a low-overhead debugging tool-set, which can be used in production environments. Similar to existing instrumentation tools, it allows administrators to instrument applications at run-time with significantly better performance than existing state-of-art tools. We use a novel two-stage process, whereby we first create place-holders in the binary at compile time and instrument them at run-time. iProbe is a standalone tool that can be used for instrumenting applications, or can be used in our debug container with Parikshan to assist the administrator in debugging. Lastly, while Parikshan is a platform to quickly attack bugs, in itself it’s a debugging platform. For the last section of this dissertation we look at how various existing debugging techniques can be adapted to live debugging, making them more effective. We first enumerate scenarios in which debugging can take place: post-facto turning livedebugging on after a bug has occurred, proactive having debugging on before a bug has happened. We will then discuss how existing debugging tools and strategies can be applied in the debug container to be more efficient and effective. We will also discuss potential new ways that existing debugging mechanisms can be modified to fit in the live debugging domain.